Kurz gesagt: Security-Header sind Zeilen, die der Webserver bei jeder Antwort mitschickt. Sie sagen dem Browser zum Beispiel, dass er nur HTTPS nutzen, keine fremden Skripte laden oder die Seite in keinem fremden Rahmen anzeigen soll. Die wichtigsten sind Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Content-Type-Options, Referrer-Policy und Permissions-Policy. Führen Sie HSTS und CSP stufenweise ein, sonst sperren Sie im schlimmsten Fall Ihre eigenen Besucher aus.
Was sind HTTP-Security-Header?
Wenn ein Browser eine Seite abruft, schickt der Server vor dem eigentlichen Inhalt einige Zeilen mit Zusatzinformationen. Diese HTTP-Header enthalten etwa den Dateityp oder Angaben zum Caching. Ein Teil davon dient der Sicherheit: Er legt Regeln fest, an die sich der Browser hält. So schützen Security-Header Besucher vor Angriffen wie Cross-Site-Scripting (XSS) oder Clickjacking.
Die Header ersetzen keine Updates und keinen sauberen Code. Sie sind eine zusätzliche Schutzschicht, die mit wenig Aufwand viel bringt. Das OWASP Secure Headers Project sammelt dazu Empfehlungen. Ein fehlender Header gehört in der OWASP Top 10:2025 zur Kategorie Security Misconfiguration, die dort auf Platz 2 steht.
Strict-Transport-Security (HSTS)
HSTS teilt dem Browser mit: Diese Domain nur noch über HTTPS aufrufen. Tippt ein Besucher später http:// ein oder klickt auf einen alten Link, wechselt der Browser selbst auf die verschlüsselte Verbindung. Ein Angreifer im selben WLAN kann die Verbindung dann nicht mehr unverschlüsselt abfangen.
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age gibt in Sekunden an, wie lange sich der Browser die Regel merkt; 31536000 entspricht einem Jahr. includeSubDomains überträgt die Regel auf alle Subdomains. Der Header wirkt laut MDN nur, wenn er über HTTPS ausgeliefert wird.
Stufenweise einführen
Prüfen Sie zuerst, ob wirklich jede Subdomain HTTPS kann, auch alte wie ein Testsystem oder ein Mailportal. Die Betreiber der HSTS-Preload-Liste empfehlen, max-age langsam zu steigern: erst 300 Sekunden (fünf Minuten), dann 604800 (eine Woche), dann 2592000 (30 Tage). Erst wenn alles läuft, folgt ein Jahr. Geht etwas schief, setzen Sie max-age=0, damit Browser die Regel wieder vergessen.
Vorsicht bei preload
Mit dem Zusatz preload und einer Anmeldung bei hstspreload.org landet Ihre Domain in einer Liste, die Browser fest eingebaut haben. Voraussetzung sind max-age von mindestens 31536000 und includeSubDomains. Der Haken: Die Aufnahme lässt sich nur schwer rückgängig machen, eine Entfernung dauert Monate. Nutzen Sie preload erst, wenn Sie sicher sind, dass die ganze Domain dauerhaft nur HTTPS nutzt.
Content-Security-Policy (CSP)
Die Content Security Policy legt fest, aus welchen Quellen der Browser Skripte, Bilder, Schriften und andere Ressourcen laden darf. Schleust ein Angreifer ein fremdes Skript ein, blockiert der Browser es, weil die Quelle nicht freigegeben ist. Das ist eine wirksame zusätzliche Schutzschicht gegen XSS. Ein einfaches Beispiel:
Content-Security-Policy: default-src 'self'; img-src 'self' https://cdn.example.com; frame-ancestors 'none'; upgrade-insecure-requestsDiese Policy erlaubt Inhalte nur von der eigenen Domain, Bilder zusätzlich von einem CDN, verbietet das Einbetten der Seite in fremde Rahmen und lässt den Browser HTTP-Adressen automatisch auf HTTPS umstellen.
Zuerst im Testmodus
Eine CSP ist oft kniffelig, weil moderne Websites viele fremde Dienste einbinden: Analyse, Karten, Videos, Schriften, Cookie-Banner. Gerade bei WordPress mit vielen Plugins kommt einiges zusammen. MDN empfiehlt, zuerst den Header Content-Security-Policy-Report-Only zu nutzen. Dann blockiert der Browser nichts, meldet aber jeden Verstoß in der Konsole. Sie sehen, welche Quellen fehlen, ergänzen die Policy und schalten erst dann scharf.
X-Frame-Options und frame-ancestors
Beim Clickjacking lädt ein Angreifer Ihre Website unsichtbar in einen iframe auf seiner eigenen Seite. Der Besucher glaubt, auf etwas Harmloses zu klicken, und löst in Wahrheit eine Aktion auf Ihrer Seite aus. Der ältere Header X-Frame-Options verhindert das:
X-Frame-Options: SAMEORIGINMit DENY darf niemand die Seite einbetten, mit SAMEORIGIN nur die eigene Domain. Umfassender ist die CSP-Anweisung frame-ancestors. Der Wert 'none' wirkt ungefähr wie DENY, außerdem lassen sich einzelne Domains freigeben. Laut MDN funktioniert frame-ancestors nicht in einem <meta>-Tag, nur als echter Header. Viele Seiten senden beide Varianten, damit auch ältere Browser geschützt sind.
Weitere wichtige Header
X-Content-Type-Options
X-Content-Type-Options: nosniffDer Wert nosniff verbietet dem Browser, den Dateityp selbst zu erraten (MIME-Sniffing). Er hält sich dann an den Typ, den der Server angibt. So wird eine hochgeladene Textdatei nicht plötzlich als Skript ausgeführt. Der Header hat praktisch keine Nebenwirkungen und gehört auf jede Website.
Referrer-Policy
Referrer-Policy: strict-origin-when-cross-originKlickt ein Besucher auf einen Link zu einer anderen Website, verrät der Browser normalerweise, woher er kommt. Die Referrer-Policy steuert, wie viel davon. Mit strict-origin-when-cross-origin erhalten fremde Seiten nur die Domain, nicht den vollen Pfad mit möglichen Parametern. Laut MDN ist das auch der Standardwert, wenn kein Header gesetzt ist. Wer noch weniger preisgeben will, nutzt no-referrer.
Permissions-Policy
Permissions-Policy: camera=(), microphone=(), geolocation=()Dieser Header legt fest, welche Browser-Funktionen die Seite und eingebettete Inhalte nutzen dürfen, etwa Kamera, Mikrofon, Standort oder Vollbild. Leere Klammern schalten eine Funktion für alle ab, (self) erlaubt sie nur der eigenen Domain. Der Header hieß früher Feature-Policy.
X-XSS-Protection
Diesen Header finden Sie noch in vielen alten Anleitungen. Er steuerte einen XSS-Filter, den Browser inzwischen entfernt haben. MDN rät, stattdessen eine Content-Security-Policy zu nutzen. Wer ihn setzt, sollte den Wert 0 verwenden.
Wo Sie Security-Header setzen
Das hängt davon ab, wie Ihre Website läuft:
- Webserver: Bei Apache geht das in der Server-Konfiguration oder in der .htaccess, etwa mit
Header always set X-Content-Type-Options "nosniff". Bei nginx nutzen Sie die Anweisungadd_header. - CDN oder Proxy: Viele Content-Delivery-Netzwerke erlauben eigene Regeln für Antwort-Header. Das ist praktisch, wenn Sie keinen Zugriff auf den Server haben.
- Hosting und Baukasten: Manche Anbieter haben im Kundenmenü ein Feld für eigene Header. Fehlt es, fragen Sie den Support.
- CMS-Plugins: Bei WordPress gibt es Erweiterungen dafür. Der Webserver ist aber meist der bessere Ort, weil die Header dann auch für Bilder und Dateien gelten.
Setzen Sie einen Header nur an einer Stelle. Sendet sowohl der Server als auch das CDN eine CSP, gelten beide gleichzeitig, und das führt schnell zu blockierten Inhalten.
Security-Header prüfen
Am schnellsten geht es im Terminal:
curl -I https://example.comDie Antwort listet alle Header der Startseite. Ohne Terminal öffnen Sie im Browser die Entwicklertools (F12), wechseln zu „Netzwerk“, laden neu und klicken auf das erste Dokument. Unter „Antwort-Header“ steht dasselbe. Mozilla bietet auf MDN außerdem das HTTP Observatory an, das die Header bewertet und Verbesserungen vorschlägt. Weitere Prüfpunkte finden Sie im Artikel Website-Sicherheit prüfen.
Typische Fehler
- HSTS mit langer Laufzeit auf Anhieb: Mit includeSubDomains ist eine Subdomain ohne gültiges Zertifikat für Besucher bis zum Ablauf von max-age gesperrt.
- preload ohne Plan: Die Domain steckt monatelang in der Liste fest.
- CSP direkt scharf geschaltet: Formulare, Karten oder der Cookie-Banner funktionieren nicht mehr.
- 'unsafe-inline' für Skripte: Damit verliert die CSP einen großen Teil ihres XSS-Schutzes.
- Header nur auf der Startseite: Prüfen Sie auch Unterseiten, Fehlerseiten und Weiterleitungen.
- Doppelte Header: Server und CDN setzen dieselbe Regel unterschiedlich.
Header ändern kaum etwas an der Ladezeit. Wenn Sie ohnehin an der Server-Konfiguration arbeiten, lohnt sich der Blick in unseren Artikel Ladezeit der Website verbessern.
Fazit
Mit X-Content-Type-Options, Referrer-Policy und Permissions-Policy erhöhen Sie die Sicherheit Ihrer Website in wenigen Minuten. HSTS und Content-Security-Policy brauchen mehr Sorgfalt: erst testen, dann langsam verschärfen. Mehr zu Verschlüsselung und Server-Einstellungen finden Sie auf unserer Themenseite Header & Verschlüsselung.
Quellen: MDN Web Docs, Artikel zu Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und X-XSS-Protection; hstspreload.org, Hinweise zu Preload und Einführung; OWASP Secure Headers Project; OWASP Top 10:2025.