Was sind Header und Verschlüsselung?
Wenn ein Browser eine Seite abruft, schickt der Server vor dem eigentlichen Inhalt einige Zeilen mit Zusatzinformationen. Diese HTTP-Header nennen etwa den Dateityp oder Angaben zum Caching. Ein Teil davon dient der Sicherheit. Er legt fest, ob der Browser nur verschlüsselte Verbindungen nutzen darf, aus welchen Quellen er Skripte laden darf und ob eine fremde Seite Ihre Website einbetten darf.
Die Verschlüsselung selbst läuft über HTTPS. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt Transportverschlüsselung für Webanwendungen grundsätzlich. Header bauen darauf auf: Einige wirken laut MDN überhaupt nur, wenn der Server sie über HTTPS ausliefert.
Header ersetzen weder Updates noch sauberen Code. Sie bilden eine zusätzliche Schutzschicht, die mit wenig Aufwand viel bringt. Das OWASP Secure Headers Project sammelt dazu Empfehlungen. Fehlende Header zählen in der OWASP Top 10:2025 zur Kategorie Security Misconfiguration, die dort auf Platz 2 steht.
Wie funktionieren Security-Header?
Der Webserver hängt die Header an jede Antwort an. Der Browser liest sie und wendet die Regeln auf die Seite an. Steht in einer Content-Security-Policy zum Beispiel, dass Skripte nur von der eigenen Domain kommen dürfen, blockiert der Browser jedes eingeschleuste fremde Skript.
Wo Sie die Header setzen, hängt vom Aufbau Ihrer Website ab. Bei Apache geht das in der Server-Konfiguration oder in der .htaccess, bei nginx mit der Anweisung add_header. Viele CDNs erlauben eigene Regeln für Antwort-Header, was hilft, wenn Sie keinen Zugriff auf den Server haben. Manche Hoster und Baukästen bieten im Kundenmenü ein Feld dafür. Bei WordPress gibt es Erweiterungen, der Webserver ist aber meist der bessere Ort, weil die Header dann auch für Bilder und Dateien gelten. Setzen Sie jeden Header nur an einer Stelle.
Die wichtigsten Bausteine
Strict-Transport-Security (HSTS)
HSTS teilt dem Browser mit, eine Domain nur noch über HTTPS aufzurufen. Der Wert max-age gibt in Sekunden an, wie lange der Browser sich das merkt, includeSubDomains überträgt die Regel auf alle Subdomains. Steigern Sie max-age stufenweise, etwa von 300 über 604800 auf 2592000 Sekunden, wie es die Betreiber der HSTS-Preload-Liste empfehlen. Mit max-age=0 vergessen Browser die Regel wieder.
Content-Security-Policy (CSP)
Die CSP legt fest, aus welchen Quellen der Browser Skripte, Bilder, Schriften und andere Ressourcen laden darf. Sie ist der wichtigste Schutz gegen XSS. Mit upgrade-insecure-requests stellt der Browser HTTP-Adressen automatisch auf HTTPS um. MDN empfiehlt, zuerst den Header Content-Security-Policy-Report-Only zu nutzen, der Verstöße meldet, ohne etwas zu blockieren.
Schutz gegen Einbetten
Beim Clickjacking lädt ein Angreifer Ihre Seite unsichtbar in einen Rahmen auf seiner Seite. X-Frame-Options mit DENY oder SAMEORIGIN verhindert das. Umfassender ist die CSP-Anweisung frame-ancestors, deren Wert 'none' ungefähr wie DENY wirkt. Laut MDN funktioniert frame-ancestors nur als echter Header und nicht in einem meta-Tag.
X-Content-Type-Options
Der Wert nosniff verbietet dem Browser, den Dateityp selbst zu erraten. 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 und Permissions-Policy
Die Referrer-Policy steuert, wie viel ein Browser beim Klick auf einen externen Link über die Herkunft verrät. Mit strict-origin-when-cross-origin erhalten fremde Seiten nur die Domain. Die Permissions-Policy legt fest, ob die Seite und eingebettete Inhalte Kamera, Mikrofon oder Standort nutzen dürfen.
Typische Fehler
- HSTS gleich mit langer Laufzeit: Eine Subdomain ohne gültiges Zertifikat bleibt dann bis zum Ablauf von max-age für Besucher gesperrt.
- preload ohne Plan: Die Aufnahme in die Preload-Liste lässt sich nur schwer rückgängig machen, eine Entfernung dauert Monate.
- CSP sofort 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: Unterseiten, Fehlerseiten und Weiterleitungen bleiben ohne Schutz.
- Doppelte Header von Server und CDN, die sich widersprechen.
- X-XSS-Protection aus alten Anleitungen: Browser haben den zugehörigen Filter entfernt; MDN rät zur CSP.
Wie Sie prüfen
Am schnellsten geht es im Terminal mit curl -I https://example.com. Die Antwort listet alle Header der Startseite. Ohne Terminal öffnen Sie im Browser die Entwicklertools mit F12, wechseln zu „Netzwerk“, laden neu und klicken auf das erste Dokument. Unter „Antwort-Header“ steht dasselbe.
Suchen Sie nach Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy und einem Schutz gegen Einbetten. Prüfen Sie zusätzlich, ob jede Adresse mit http:// auf https:// weiterleitet und ob das Zertifikat gültig ist. Die Konsole zeigt Warnungen zu gemischten Inhalten sowie CSP-Verstöße, solange die Policy im Testmodus läuft. Wiederholen Sie die Prüfung auf einigen Unterseiten und nach jeder Änderung an Server, CDN oder Hosting.
Häufige Fragen
Welche Security-Header braucht jede Website?
Als Grundausstattung gelten Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy und ein Schutz gegen Einbetten über X-Frame-Options oder frame-ancestors.
Macht HTTPS eine Website sicher?
HTTPS schützt die Übertragung zwischen Browser und Server. Lücken in Plugins, schwache Passwörter oder offene Dateien behebt es nicht.
Was bedeutet HSTS preload?
Die Domain landet in einer Liste, die Browser fest eingebaut haben. Voraussetzung sind ein max-age von mindestens 31536000 Sekunden und includeSubDomains.
Bremsen Security-Header die Ladezeit?
Header ändern kaum etwas an der Ladezeit. Mehr zur Geschwindigkeit lesen Sie im Artikel Ladezeit der Website verbessern.
