Was sind Security Header?

Einfach erklärt

Security Header sind kurze Anweisungen, die Ihre Website bei jedem Aufruf unsichtbar an den Browser mitschickt. Man kann sie sich wie die Hausordnung am Eingang vorstellen: „Nur verschlüsselt eintreten“, „Keine fremden Skripte ausführen“, „Diese Seite darf nicht in fremde Seiten eingebaut werden“, „Kamera und Mikrofon bleiben aus“. Der Browser hält sich daran und schützt so Ihre Besucher.

Wovor sie schützen

• Eingeschleuster Code: Gelingt es jemandem, ein Skript in Ihre Seite zu schmuggeln, etwa über ein Kommentarfeld, verhindert eine gute Content Security Policy, dass es ausgeführt wird.
• Gefälschte Oberflächen: Ohne Schutz kann eine fremde Seite Ihre Seite unsichtbar einbetten und Besucher dazu bringen, auf etwas zu klicken, das sie nicht sehen. Fachleute nennen das Clickjacking.
• Datenabfluss: Eine Anweisung legt fest, wie viel von der Adresse, auf der ein Besucher gerade ist, an fremde Seiten weitergegeben wird. Adressen können Suchbegriffe oder Kundennummern enthalten.

Was Sie tun können

Security Header werden in der Konfiguration des Webservers oder im Hosting gesetzt und kosten nichts. Die meisten sind schnell ergänzt. Nur die Content Security Policy braucht Sorgfalt, weil eine zu strenge Regel Teile der Website lahmlegen kann. Bitten Sie die Firma, die Ihre Website betreut, die Header zu setzen und die Content Security Policy zuerst im Testbetrieb laufen zu lassen.

Was Header nicht leisten

Header sind eine zweite Verteidigungslinie. Sie machen eine Sicherheitslücke in der Website-Software nicht ungeschehen, sondern erschweren nur, sie auszunutzen. Und sie wirken nur in Browsern, die sie kennen.

Die üblichen Header

Moderner Ersatz für X-Frame-Options ist die CSP-Anweisung frame-ancestors. Sie wirkt nur als HTTP-Header, nicht im <meta>-Tag. X-XSS-Protection gehört nicht mehr dazu: OWASP rät, den Header nicht zu setzen oder ausdrücklich mit 0 abzuschalten.

Beispiel für nginx:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

always setzt die Header auch bei Fehlerantworten. Beim Shared Hosting mit Apache geht dasselbe in der .htaccess, sofern der Hoster mod_headers und solche Einstellungen dort erlaubt:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

In der Permissions-Policy bedeutet eine leere Liste (), dass keine Herkunft die Funktion nutzen darf, auch die eigene Seite nicht.

Typische Fehler

• Vererbung in nginx. add_header wird nur übernommen, solange die aktuelle Ebene keine eigenen add_header setzt. Ein location-Block mit einem einzigen eigenen Header verliert alle übrigen.
• Werte ohne Wirkung. X-Frame-Options: ALLOW-FROM kennen aktuelle Browser nicht. X-Content-Type-Options wirkt nur mit nosniff.
• Referrer-Policy: unsafe-url gibt die vollständige Adresse samt Parametern an jede fremde Seite weiter, no-referrer-when-downgrade an jede verschlüsselte.
• Doppelte Header, je einmal von Anwendung und Proxy, mit widersprüchlichen Werten.
• CSP nur im <meta>-Tag. Dann fehlt der Schutz durch frame-ancestors.
• Nur die Startseite geprüft. Unterseiten, Fehlerseiten und Dateien aus einem anderen location-Block oder von einem anderen Server können ohne Header ausgeliefert werden.

Prüfen

curl -sI https://ihre-firma.de/ | grep -i -E '^(strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy)'

Eine Übersicht mit Bewertung liefert zum Beispiel das HTTP Observatory von Mozilla.