Was sind Security-Header? Was jeder einzelne bewirkt und wie Sie sie einrichten

Security-Header sind HTTP-Antwortheader, die den Browser anweisen, Schutzfunktionen einzuschalten, die er ohnehin mitbringt: Verbindungen nur über HTTPS aufbauen, keine Skripte aus unerwarteten Quellen ausführen, das Einbetten dieser Seite in fremde Frames unterbinden und so weiter. Verwundbaren Code reparieren sie nicht, aber sie erschweren mehrere verbreitete Angriffe – etwa Cross-Site-Scripting, Clickjacking und Protokoll-Downgrades – erheblich oder begrenzen den Schaden, wenn es doch dazu kommt.

So sehen Sie, welche Header Ihre Website sendet

• Im Browser: Öffnen Sie die Entwicklertools, wechseln Sie zum Tab „Netzwerk“, laden Sie die Seite neu, klicken Sie auf die erste Anfrage (das Dokument) und sehen Sie sich die Antwortheader an.
• Im Terminal: curl -I https://example.com gibt die Header aus.
• Mit einem Prüftool: Rudras kostenloser Website-Sicherheitscheck prüft, ob die Website HTTPS verwendet und unverschlüsseltes HTTP dorthin weiterleitet, ob das TLS-Zertifikat gültig ist und nicht kurz vor dem Ablauf steht, und liest die Werte von HSTS, Content-Security-Policy, X-Frame-Options (oder der CSP-Direktive frame-ancestors), X-Content-Type-Options, Referrer-Policy und Permissions-Policy aus. Außerdem meldet er Server- oder X-Powered-By-Header, die Versionsnummern der eingesetzten Software verraten, und prüft Cookie-Flags sowie CORS.

Dass ein Header vorhanden ist, sagt allein noch nichts aus. Eine Content-Security-Policy, die Skripte von überall zulässt, ist zwar vorhanden, schützt aber kaum – deshalb wertet Rudra auch die Werte aus: Ein HSTS-max-age von weniger als 180 Tagen, eine CSP mit 'unsafe-inline' oder einem * in script-src oder ein ungültiger Wert für X-Frame-Options werden als schwach gemeldet. Mit den folgenden Abschnitten können Sie Ihre eigenen Werte einschätzen.

Die Header im Einzelnen

Strict-Transport-Security (HSTS)

Weist den Browser an, für Ihre Domain eine festgelegte Zeit lang HTTPS zu verwenden – auch wenn jemand http:// eintippt oder einem alten Link folgt. Damit schließt sich das Zeitfenster, in dem ein Angreifer im Netzwerk die erste unsichere Anfrage abfangen könnte. Ein gängiger Wert ist Strict-Transport-Security: max-age=63072000; includeSubDomains (zwei Jahre).

• Beginnen Sie mit einem kurzen max-age, etwa 300 Sekunden, und erhöhen Sie den Wert, sobald Sie sicher sind, dass jede Seite über HTTPS funktioniert.
• Ergänzen Sie includeSubDomains nur, wenn jede Subdomain HTTPS ausliefert – auch alte, die Sie vielleicht vergessen haben.
• Das Flag preload schreibt zusammen mit dem Eintrag in die Preload-Liste der Browser HTTPS für Ihre Domain fest in die Browser hinein. Das lässt sich nur mühsam und langsam rückgängig machen – setzen Sie es also zuletzt und ganz bewusst.
• Browser beachten HSTS nur, wenn sie den Header über HTTPS erhalten.

Content-Security-Policy (CSP)

Eine Liste der Quellen, aus denen die Seite Skripte, Styles, Bilder, Schriften und Frames laden darf. Gelingt es einem Angreifer, ein Skript einzuschleusen, verhindert eine gute CSP, dass der Browser es ausführt. Sie ist der wirkungsvollste Header in dieser Liste – und zugleich derjenige, bei dem am leichtesten etwas schiefgeht. Ein vernünftiger Ausgangspunkt für eine einfache Website:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Damit sind Ressourcen nur vom eigenen Origin erlaubt (plus eingebettete data:-Bilder), Plugins werden blockiert, eingeschleuste <base>-Tags können relative URLs nicht mehr umleiten, und das Einbetten in Frames wird unterbunden. Echte Websites nutzen Analyse-Tools, Schriften, eingebettete Inhalte und Zahlungsanbieter, die jeweils ausdrücklich erlaubt werden müssen, und Inline-Skripte werden blockiert, sofern Sie sie nicht per Nonce oder Hash freigeben. Führen Sie die Richtlinie zunächst mit Content-Security-Policy-Report-Only ein: Der Browser meldet Verstöße in der Konsole (und an einen Reporting-Endpunkt, falls Sie einen angeben), ohne etwas zu blockieren – so können Sie die Richtlinie anpassen, bevor Sie sie durchsetzen.

X-Content-Type-Options

X-Content-Type-Options: nosniff hält Browser davon ab, den Typ einer Datei zu erraten und zum Beispiel eine hochgeladene Textdatei als Skript auszuführen. Der Header kennt keine weiteren Einstellungen und richtet nur selten Schaden an, solange Ihr Server korrekte Content-Type-Header sendet. Setzen Sie ihn überall.

Schutz vor Clickjacking: frame-ancestors und X-Frame-Options

Beim Clickjacking werden Menschen dazu verleitet, etwas auf Ihrer Website anzuklicken, während diese unsichtbar im Frame einer anderen Website steckt. Das zeitgemäße Mittel dagegen ist die CSP-Direktive frame-ancestors 'none' (Einbetten grundsätzlich verbieten) oder frame-ancestors 'self' (nur durch Ihre eigenen Seiten). Das ältere X-Frame-Options: DENY beziehungsweise SAMEORIGIN erfüllt in älteren Browsern denselben Zweck, und beides zu senden schadet nicht. Müssen Ihre Seiten auf bestimmten Partner-Websites eingebettet werden, führen Sie deren Origins in frame-ancestors auf.

Referrer-Policy

Legt fest, wie viel von der aktuellen URL an andere Websites übermittelt wird, wenn Besucher einem Link folgen oder eine Ressource geladen wird. URLs können Suchbegriffe, IDs oder Tokens enthalten, die nicht nach außen dringen sollen. Referrer-Policy: strict-origin-when-cross-origin sendet innerhalb Ihrer Website die vollständige URL, an andere Websites aber nur den Origin (https://example.com) und beim Wechsel von HTTPS zu HTTP gar nichts. Moderne Browser verwenden dies bereits als Standard; wer den Header ausdrücklich setzt, sorgt für ein einheitliches Verhalten.

Permissions-Policy

Schaltet mächtige Browserfunktionen ab, die Ihre Website nicht nutzt, sodass weder Ihr eigener Code noch ein eingebetteter Drittanbieter sie anfordern kann. Für eine Website, die weder Kamera noch Mikrofon noch Standort benötigt: Permissions-Policy: camera=(), microphone=(), geolocation=().

Header, die Sie entfernen oder weglassen sollten

• Header, die Versionen verraten. Server- und X-Powered-By-Werte mit Versionsnummern zeigen Angreifern genau, welche Software in welcher Version sie ins Visier nehmen müssen. Entfernen Sie die Header oder zumindest die Versionsangabe (in nginx mit server_tokens off;).
• X-XSS-Protection steuerte einen Filter, den moderne Browser inzwischen entfernt haben. Verlassen Sie sich nicht darauf; lassen Sie den Header weg oder setzen Sie ihn auf 0.

So richten Sie Security-Header ein

nginx

• add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
• add_header X-Content-Type-Options "nosniff" always;
• add_header Referrer-Policy "strict-origin-when-cross-origin" always;
• add_header X-Frame-Options "DENY" always;

Das Flag always sorgt dafür, dass der Header auch bei Fehlerantworten gesendet wird. Achten Sie auf die Vererbung: Enthält ein location-Block auch nur eine einzige add_header-Direktive, erbt er die auf server-Ebene definierten Header nicht mehr – sie verschwinden dann stillschweigend von diesen URLs. Wiederholen Sie die Header dort oder legen Sie sie in einer gemeinsamen Datei ab, die Sie per include einbinden.

Apache

Ist mod_headers aktiviert, tragen Sie im Virtual Host oder in der .htaccess ein: Header always set X-Content-Type-Options "nosniff" – und nach demselben Muster jeden weiteren Header, etwa Header always set Referrer-Policy "strict-origin-when-cross-origin".

Next.js

Geben Sie in der next.config.js die Header für jeden Pfad zurück: async headers() { return [{ source: '/:path*', headers: [{ key: 'X-Content-Type-Options', value: 'nosniff' }, { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' }] }]; }. Für eine CSP mit Nonces erzeugen Sie den Header stattdessen pro Anfrage in der Middleware, wie es die Next.js-Dokumentation beschreibt.

Netlify, Cloudflare Pages und ähnliche Hoster

Diese Hoster lesen eine _headers-Datei in Ihrem veröffentlichten Verzeichnis. Schreiben Sie ein Pfadmuster in eine Zeile, etwa /*, und darunter jeden Header eingerückt in eine eigene Zeile, etwa X-Content-Type-Options: nosniff. Bei Vercel entspricht dem der Abschnitt headers in der vercel.json. Wenn Sie ein CDN nutzen, kann in der Regel auch dieses Header hinzufügen.

Sicher einführen

1. Setzen Sie zuerst die risikoarmen Header: X-Content-Type-Options, Referrer-Policy, Permissions-Policy und den Schutz vor Clickjacking.
2. Aktivieren Sie HSTS mit einem kurzen max-age und erhöhen Sie den Wert über einige Wochen.
3. Rollen Sie die CSP im Report-Only-Modus aus, beheben Sie, was gemeldet wird, und setzen Sie sie erst dann durch.
4. Testen Sie die Abläufe, an denen Drittanbieter beteiligt sind: Login, Checkout und Zahlungs-Frames, eingebettete Videos, Karten, Chat-Widgets und Analyse-Tools.
5. Prüfen Sie mit dem Sicherheitscheck nach – und erneut, sobald Sie ein weiteres Drittanbieter-Tool einbinden.

Häufige Fehler

• Eine strenge CSP von einer anderen Website kopieren und damit Zahlungen, Analyse-Tools oder eingebettete Inhalte lahmlegen.
• Eine CSP voller 'unsafe-inline', 'unsafe-eval' und Wildcards schreiben, die zwar die Prüfung auf Vorhandensein besteht, aber kaum schützt.
• HSTS mit preload setzen, bevor jede Subdomain für HTTPS bereit ist.
• Header in einem HTML-<meta>-Tag setzen. Das funktioniert nur für einige CSP-Direktiven; HSTS, frame-ancestors und X-Frame-Options werden in Meta-Tags ignoriert.
• Header sowohl in der Anwendung als auch im Proxy setzen, sodass Antworten doppelte oder widersprüchliche Werte enthalten.
• Header als Ersatz dafür betrachten, Software zu aktualisieren, Eingaben zu validieren und Ausgaben zu maskieren.

Was Header und Header-Prüfungen nicht abdecken

Header sind nur eine Schutzschicht. Eine Header-Prüfung findet weder ein veraltetes Plugin noch ein schwaches Admin-Passwort, eine Injection-Lücke oder eine offen zugängliche Backup-Datei. Auch Cookies verdienen eine eigene Prüfung: Session-Cookies sollten die Attribute Secure, HttpOnly und SameSite tragen. Rudras Sicherheitscheck meldet diese Flags für Cookies, die die Antwort der Seite selbst setzt (mit Namen, nie mit Wert); die Einzelheiten finden Sie unter Cookie-Sicherheit prüfen, und unter Website-Sicherheit prüfen lesen Sie, was eine passive Prüfung verrät und was nicht. Für einen breiteren Blick auf den Zustand Ihrer Website führen Sie ein vollständiges Website-Audit durch.