it-swarm.com.de

Sicherheitskopfzeilen für eine Web-API

Ich habe gerade ein Setup erhalten, eine Golang-Web-API hinter einem Caddy-Server, der standardmäßig über Let's Encrypt über HTTPS verfügt. Der Server leitet alle Anforderungen an die Web-API weiter. Also habe ich meinen Webserver "Sicherheit" auf Websites wie securityheaders.io getestet. Sie gaben mir ein F, also fügte ich die von ihnen verlangten Überschriften hinzu und bekam ein A.

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

Dies sind die Header, die ich derzeit habe, aber ich würde gerne wissen, ob sie für die Sicherheit notwendig sind, wenn ich keine Website, sondern einen API-Webserver mache

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

Also im Grunde alle diese Sicherheitsheader, die notwendig sind, wenn Sie nur Ihre API anfordern möchten?

14
Whiteclaws

Das Abhaken von Headern von einer Liste ist nicht die beste Methode, um die Sicherheit einer Site zu gewährleisten. Dienste wie securityheaders.io können Sie in die richtige Richtung weisen, aber alles, was sie tun, ist, mit einer Liste vorgeschlagener Einstellungen zu vergleichen, ohne dass ein Kontext zu Ihrer Anwendung besteht. Folglich haben einige der Vorschläge keine Auswirkungen auf die Sicherheit eines API-Endpunkts, der nur JSON-Antworten liefert.

  • Strict-Transport-Security Ist sinnvoll, da es garantiert, dass Benutzer nach ihrem ersten Besuch und bis zum Timeout von max-age Direkt über HTTPS eine Verbindung zu Ihrer Site herstellen, wodurch Downgrade-Angriffe verhindert werden. Sogar ein API-Endpunkt sollte mit SSL gesichert werden. Behalten Sie also diesen Header bei.

  • Access-Control-Allow-Methods: GET, POST, OPTIONS Ist per se keine Sicherheitsoption. Wenn Ihre API über CORS Preflight-Anforderungen funktioniert, müssen Sie entscheiden, welche Methoden Sie für die Verwendung von Cross-Origin-Sites zulassen. Durch Deaktivieren von CORS kann Ihre API möglicherweise nicht verfügbar sein. Ob diese bestimmte Einstellung sinnvoll ist, hängt von Ihrer Implementierung ab.

  • X-XSS-Protection: 1; mode=block Kann eine gute Empfehlung für reguläre Websites sein, da es den XSS Auditor (der in WebKit-Browsern, aber nicht in Firefox implementiert ist) anweist, die Website nicht zu rendern, wenn ein reflektierter XSS-Versuch erkannt wird. Für eine API, die nur JSON-Antworten bereitstellt und keinen aktiven Inhalt bereitstellt, bringt dieser Header jedoch keine Vorteile.

  • X-Content-Type-Options: nosniff Verhindert, dass Browser Annahmen über den Inhaltstyp treffen, wenn die Site den Typ nicht korrekt deklariert hat. Wenn Sie eine JSON-API ausführen, sollten Sie die Antworten mit Content-Type: application/json Bereitstellen. Wenn Sie dies richtig machen, müssen Sie die Direktive nosniff nicht hinzufügen.

  • X-Frame-Options: Deny Verhindert, dass eine Website Ihre Website in einen HTML-Frame einbettet. Diese Option stoppt Clickjacking-Angriffe , wenn ein Angreifer Benutzer dazu verleitet, über einen getarnten Rahmen mit Ihrer Website zu interagieren. Ohne interaktive Elemente besteht jedoch ein begrenztes Risiko durch Cross-Origin-Framing. Da es jedoch fortgeschrittene Angriffe gibt, bei denen Inhalte aus dem Frame gezogen werden, die JSON-Antworten offenlegen könnten, möchten Sie diesen Header möglicherweise weiterhin dort belassen.

  • Content-Security-Policy -Header steuern, mit welchen Inhalten von welchem ​​Ursprung Ihre Website interagieren darf (Skripte, Stylesheets, Bilder usw.). Ihre Einstellung "script-src 'self' Bedeutet, dass nur Skripte desselben Ursprungs geladen werden dürfen. Ein CSP ist nützlich für reguläre Websites, macht jedoch für Ihren API-Endpunkt keinen Sinn, da Sie keinen aktiven Inhalt bereitstellen, der vom CSP gesteuert werden könnte.

  • Der Header Server gibt Informationen über den Server und die darauf ausgeführte Software an. Es wird oft empfohlen, diesen Header überhaupt nicht zu senden, um nichts über Backend-Software und -Versionen preiszugeben.

32
Arminius