HTTP-Sicherheitsheader erklärt: CSP, HSTS und mehr
Was CSP, HSTS und die anderen HTTP-Sicherheitsheader tatsächlich tun, wie man sie einrichtet und welchen Angriff jeder verhindert, ohne Fachjargon.
rabbitclip-TeamVeröffentlicht: 4 Min. Lesezeit
Kurz gesagt
HTTP-Sicherheitsheader sind Regeln, die ein Webserver jeder Antwort mitgibt und die dem Browser sagen, wie er sich verhalten soll. CSP schränkt ein, von welchen Quellen Scripts und Bilder geladen werden dürfen, HSTS zwingt den Browser, immer eine verschlüsselte Verbindung zu nutzen, und kleinere wie X-Content-Type-Options und Referrer-Policy schließen Risiken, die genauso real sind. Keiner von ihnen braucht eigenen Code; ein paar Zeilen in der Server- oder CDN-Konfiguration genügen.
Lässt die Website einer Anwaltskanzlei ein Werbescript eines Drittanbieters ohne korrekt eingerichtete CSP laufen, kann dieses Script fast jeden beliebigen Code in die Seite einschleusen; auf einer Seite, auf der jemand gerade ein Formular ausfüllt, ist dieses Risiko nicht abstrakt. Sicherheitsheader begrenzen von vornherein, was ein solches Script überhaupt tun kann.
Was ist ein HTTP-Sicherheitsheader, und wie funktioniert er?
Ein HTTP-Sicherheitsheader ist eine zusätzliche Anweisungszeile, die der Server mit jeder Antwort mitschickt; der Browser liest sie und schränkt die Seite entsprechend ein. Header ändern nicht den Seiteninhalt, nur was der Browser mit diesem Inhalt tun darf.
Sie hinzuzufügen erfordert kein neues Feature; ein paar Zeilen in der Konfiguration von Nginx, Apache, Cloudflare oder einem Framework wie Next.js reichen aus. Einmal korrekt eingerichtet, gehen sie bei jeder Seitenanfrage automatisch mit hinaus.
Was leistet Content-Security-Policy (CSP) tatsächlich?
CSP legt fest, von welchen Adressen eine Seite Scripts, Bilder, Schriften und Stile laden darf. Laut OWASPs Leitfaden zu HTTP-Headern ist CSP der einzige Header, der bereits in eine Seite eingeschleusten Code noch wirksam an der Ausführung hindern kann; das macht ihn zu einer der wirksamsten Verteidigungen gegen Cross-Site-Scripting (XSS).
Der schwierige Teil der Einrichtung ist, wirklich jede von der Seite genutzte Drittquelle aufzulisten, Analytics, einen Schriftdienst, einen Zahlungsanbieter; wird eine vergessen, funktioniert ein Teil der Seite nicht mehr. Deshalb läuft CSP meist zunächst im reinen Report-Modus, die Protokolle werden geprüft, bevor in den erzwingenden Modus umgeschaltet wird.
Was garantiert HSTS (Strict-Transport-Security)?
HSTS sagt dem Browser, sich nie wieder unverschlüsselt (http://) mit einer Seite zu verbinden; die Anweisung wird browserseitig gespeichert, sodass die Verbindung selbst dann automatisch auf https angehoben wird, wenn jemand http in die Adresszeile eingibt. Das verhindert, dass eine Verbindung mittendrin auf unverschlüsselt heruntergestuft wird, einen Man-in-the-Middle-Angriff.
MDNs empfohlener Aufbau hält die max-age lang, etwa zwei Jahre, bezieht Subdomains mit ein und kann bei der Preload-Liste eingereicht werden; bevor man der Preload-Liste beitritt, muss aber jede Subdomain wirklich über https laufen, denn von dieser Liste wieder herunterzukommen ist nicht einfach.
Wie wird ein Basis-Header-Set eingerichtet?
Für eine kleine Unternehmensseite sind die folgenden fünf Header ein vernünftiger Ausgangspunkt; jeder schließt ein anderes Risiko.
- Content-Security-Policy: schränkt ein, woher Scripts und Ressourcen geladen werden dürfen
- Strict-Transport-Security: hält die Verbindung jederzeit verschlüsselt
- X-Content-Type-Options: nosniff, verhindert, dass der Browser den Dateityp falsch errät
- Referrer-Policy: schränkt ein, welche Seiteninformationen an andere Seiten durchsickern
- Permissions-Policy: begrenzt den Zugriff auf Browserfunktionen wie Kamera und Standort
Header testen und fehlerfrei halten
Ein falsch eingerichteter Header kann die Seite sichtbar zerschießen oder still eine Funktion abschalten; beides muss vor dem Livegang getestet werden. Die Entwicklerkonsole des Browsers zeigt CSP-Verstöße direkt an; wird eine Ressource blockiert, nennt die Konsole sie und erklärt, warum.
Änderungen sollten zuerst in einer Testumgebung ausprobiert werden, dann auf einer risikoarmen Live-Seite; sie gleichzeitig auf der ganzen Seite auszurollen, riskiert, eine unerwartete Drittintegration zu zerstören.
Häufige Fehler
Sicherheitsheader können zu einer einmal eingestellten und dann vergessenen Einstellung werden; das führt zu einem Bruch, den niemand bemerkt, bis eine neue Integration hinzukommt.
- CSP mit unsafe-inline lockern, was den Zweck des Headers weitgehend zunichtemacht
- HSTS ohne vorheriges Testen zur Preload-Liste hinzufügen
- die CSP-Liste nicht aktualisieren, wenn ein neues Drittscript hinzukommt
- Header nur auf der Startseite setzen und den Rest der Seite vergessen
HTTP-Sicherheitsheader ändern nicht, wie eine Seite aussieht; sie legen fest, was der Browser mit ihr tun darf. Ihre Einrichtung ist eine einmalige Aufgabe, ihre Pflege ist es nicht. Ein Erstgespräch mit rabbitclip ist ein guter Ort, um zu prüfen, welche Header Ihre aktuelle Seite tatsächlich hat.
Häufige Fragen
Beeinflussen Sicherheitsheader das SEO?
Nicht direkt, aber Header wie HSTS, die HTTPS erzwingen, sind ein indirektes positives Signal für Suchmaschinen, denen sichere Verbindungen wichtig sind.
Kann das Einrichten von CSP eine funktionierende Seite zerstören?
Ja, bei falscher Konfiguration. Zuerst im Report-Modus zu testen und die Protokolle zu prüfen, bevor in den erzwingenden Modus gewechselt wird, senkt dieses Risiko.
Wo werden diese Header konfiguriert?
In der Konfiguration von Nginx, Apache, Cloudflare oder einem Framework wie Next.js; die Syntax unterscheidet sich, die Logik bleibt gleich.
Braucht eine kleine Seite diese Header wirklich?
Ja. Die Größe spielt keine Rolle; jede Seite mit Formular, Login oder Drittscripts steht vor denselben grundlegenden Risiken.
