Security Headers Check: fehlende HTTP-Sicherheitsheader finden und beheben

1. Header selbst prüfen: DevTools und curl

Öffnen Sie in Chrome oder Edge die DevTools, wählen Sie das Panel Network und laden Sie die Seite neu. Klicken Sie auf die erste Anfrage (das HTML-Dokument), öffnen Sie den Tab Headers und scrollen Sie zu Response Headers. Aktivieren Sie Preserve log, damit Anfragen über Seitenwechsel und Weiterleitungen hinweg erhalten bleiben, und Disable cache, damit Sie eine frische Antwort statt einer aus dem Cache sehen (Chrome-DevTools-Referenz zum Network-Panel). Bei deutscher Spracheinstellung tragen diese Bedienelemente übersetzte Namen. Die Netzwerkanalyse in Firefox funktioniert genauso.

Im Terminal zeigt curl genau das, was der Server sendet:

curl -sS -D - -o /dev/null https://example.com/

Mit -L folgt curl Weiterleitungen und zeigt die Header jedes Zwischenschritts. Unter Windows rufen Sie curl.exe auf und schreiben -o NUL. curl -I ist kürzer, schickt aber eine HEAD- statt einer GET-Anfrage, und manche Anwendungen behandeln HEAD in einem anderen Codepfad. Bestätigen Sie Ihre Befunde deshalb mit GET.

Wiederholen Sie die Prüfung für die http://-Adresse (sie sollte mit einer 301- oder 308-Weiterleitung auf HTTPS antworten), für den jeweils anderen Hostnamen (www oder die Domain ohne www), für eine Seite, die es nicht gibt, eine Login-Seite, eine API-Antwort und eine statische Datei. Anwendung, Webserver und CDN setzen in diesen Fällen oft unterschiedliche Header, und es zählt nur, was beim Browser ankommt.

2. Was jeder Header bewirkt und ein sicherer Startwert

Mit nosniff verlässt sich der Browser auf den angegebenen Content-Type und blockiert Skripte und Stylesheets, die mit einem falschen Typ ankommen. Prüfen Sie diese Typen also, bevor Sie den Header aktivieren. Ohne Referrer-Policy verwenden aktuelle Browser bereits strict-origin-when-cross-origin; OWASP empfiehlt trotzdem, den Wert für ältere Browser ausdrücklich zu senden; no-referrer ist die strengere Wahl, wenn keiner der Dienste, auf die Sie angewiesen sind, den Referrer braucht. In der Permissions-Policy schaltet () eine Funktion in der Seite und in allen darin eingebetteten Frames ab; erlauben Sie eine Funktion nur für den Origin des Widgets, das sie wirklich braucht. COOP same-origin hilft gegen sogenannte XS-Leaks (Cross-Site Leaks), kann aber Login- oder Zahlungs-Pop-ups von einem anderen Origin stören.

3. Content-Security-Policy und frame-ancestors

Die CSP sagt dem Browser, woher eine Seite Skripte, Styles, Bilder, Frames und Verbindungen laden darf. Sie begrenzt, was eingeschleuster Code anrichten kann; korrektes Escaping und Eingabevalidierung ersetzt sie nicht. Der CSP-Leitfaden von MDN empfiehlt eine strikte CSP auf Basis einer für jede Antwort neu erzeugten Nonce oder von Hashes statt einer langen Liste erlaubter Hosts. 'unsafe-inline' hebelt einen großen Teil des Schutzes aus, und der Browser ignoriert es in jeder Direktive, die zusätzlich eine Nonce oder einen Hash enthält. Schwierig wird eine strikte Richtlinie meist durch Drittanbieter-Code, der weitere Skripte nachlädt, etwa Tag-Manager, Consent-Banner oder Chat-Widgets. Halten Sie deshalb für jede Ausnahme fest, warum es sie gibt.

default-src ist die Rückfallebene für Fetch-Direktiven wie script-src, nicht aber für frame-ancestors: Eine Richtlinie mit default-src 'none' erlaubt trotzdem jeder Website, die Seite einzubetten. Setzen Sie deshalb ausdrücklich frame-ancestors 'self' oder 'none'; Letzteres entspricht in etwa X-Frame-Options: DENY (MDN). Laut dem OWASP HTTP Headers Cheat Sheet macht frame-ancestors X-Frame-Options in Browsern, die die Direktive unterstützen, überflüssig, während X-Frame-Options ältere Browser abdeckt; senden Sie beide, sollten sie dieselbe Einbettung erlauben. Zwei Fallen: frame-ancestors, eine Report-Only-Richtlinie und X-Frame-Options wirken nicht in einem <meta>-Tag, und X-Frame-Options: ALLOW-FROM führt dazu, dass moderne Browser den gesamten Header ignorieren.

Als erster Entwurf für eine Website ohne Drittanbieter-Skripte eignet sich die empfohlene Richtlinie des OWASP Secure Headers Project:

default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests

Sie blockiert Inline-Skripte und -Styles sowie alles, was von anderen Hosts geladen wird. Rechnen Sie anfangs also mit vielen Meldungen; genau deshalb startet sie als Report-Only (Abschnitt 8). Übernehmen Sie nur die CSP-Zeile: Das vollständige Set des Projekts enthält auch Werte wie Cache-Control: no-store und Clear-Site-Data, die bei jeder Antwort das Caching abschalten und Cookies sowie gespeicherte Daten der Besucher löschen würden. Bei JSON-API-Antworten, die der Browser nicht darstellt, bringt eine CSP wenig.

4. HSTS: max-age schrittweise erhöhen und Preload gut überlegen

Strict-Transport-Security weist den Browser an, den Host nur noch per HTTPS aufzurufen und spätere http://-Anfragen automatisch umzustellen. Kommt der Header über unverschlüsseltes HTTP, ignorieren Browser ihn. Senden Sie ihn deshalb mit HTTPS-Antworten, nicht mit der Weiterleitung von HTTP auf HTTPS. Den allerersten Aufruf eines Besuchers kann er allein nicht schützen (MDN).

Bedenken Sie die Kehrseite: Auf einem HSTS-Host können Besucher Zertifikatsfehler nicht wegklicken, ein abgelaufenes Zertifikat sperrt wiederkehrende Besucher also aus. Öffentliche TLS-Zertifikate, die seit dem 15. März 2026 ausgestellt werden, dürfen höchstens 200 Tage gültig sein (CA/Browser Forum), und Let’s Encrypt verschickt keine Ablauf-Erinnerungen mehr per E-Mail. Richten Sie deshalb zuerst die automatische Erneuerung und eine eigene Überwachung des Ablaufdatums ein. Der Leitfaden zu SSL/TLS und Security-Headern behandelt die Zertifikatsseite.

Erhöhen Sie max-age (in Sekunden) stufenweise, wie hstspreload.org empfiehlt, und prüfen Sie bei jeder Stufe, ob etwas nicht mehr funktioniert: 300 (5 Minuten), 604800 (1 Woche), 2592000 (1 Monat), dann 31536000 (1 Jahr) oder 63072000 (2 Jahre, der Wert von OWASP). max-age=0 hebt die Richtlinie auf, allerdings nur über HTTPS und nur für Besucher, die wiederkommen und den Header erhalten. Ergänzen Sie includeSubDomains erst, wenn jede Subdomain über HTTPS funktioniert, und lassen Sie zusätzlich jede Subdomain ihren eigenen Header senden.

Preload trägt Ihre Domain fest in die Browser ein, sodass schon der erste Aufruf HTTPS nutzt. Die Anmeldeseite hstspreload.org empfiehlt inzwischen HSTS, aber kein Preloading: Chrome und Safari stellen HTTP-Navigationen ohnehin auf HTTPS um, Preload bringt also wenig, und eine Streichung von der Liste braucht Monate, bis sie bei den Nutzern ankommt. Das OWASP HTTP Headers Cheat Sheet führt preload in seinem Beispielheader weiterhin auf, der empfohlene Wert des OWASP Secure Headers Project dagegen nicht. Setzen Sie es nicht standardmäßig und übernehmen Sie es nicht ungeprüft aus einer Vorlage.

5. Cookie-Attribute: Secure, HttpOnly und SameSite

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure sorgt dafür, dass der Browser das Cookie nur über HTTPS sendet (localhost ausgenommen). Vor JavaScript verbirgt es das Cookie nicht.
• HttpOnly verhindert, dass Skripte auf der Seite das Cookie lesen (etwa über document.cookie); der Browser sendet es aber weiterhin mit passenden Anfragen. Es erschwert also den Cookie-Diebstahl per XSS, verhindert XSS selbst aber nicht.
• SameSite entscheidet, ob das Cookie bei websiteübergreifenden Anfragen mitgeht. Mit Strict nie. Mit Lax nur bei GET-Navigationen auf oberster Ebene von einer anderen Website, etwa wenn jemand einem Link auf Ihre Seite folgt. Mit None immer, und None setzt Secure voraus. Der Standardwert unterscheidet sich zwischen Browsern; setzen Sie das Attribut deshalb ausdrücklich.
• Das Namenspräfix __Host- lässt den Browser das Cookie nur akzeptieren, wenn es mit Secure von einem HTTPS-Origin gesetzt wird, mit Path=/ und ohne Domain-Attribut.

Verwenden Sie für Session-Cookies Lax oder Strict, solange kein Ablauf wirklich None braucht, etwa die Rückleitung von einem Zahlungsdienst oder Login-Anbieter, die per POST von einer anderen Website zurückkommt. Das OWASP Session Management Cheat Sheet sieht SameSite als zusätzliche Schutzschicht gegen Cross-Site Request Forgery (CSRF), nicht als Ersatz für CSRF-Tokens.

6. Header, die weg können: X-XSS-Protection und andere Altlasten

• X-XSS-Protection schaltete in alten Browsern einen Filter ein, der selbst XSS-Lücken erzeugen konnte (MDN). OWASP rät, den Header nicht zu setzen oder ihn mit 0 abzuschalten; an seine Stelle tritt die CSP.
• Expect-CT: OWASP rät davon ab und empfiehlt unter Verweis auf Mozilla, ihn aus bestehenden Konfigurationen zu entfernen.
• Public-Key-Pins (HPKP) wurde 2018 aus Chromium entfernt und wird von keinem modernen Browser unterstützt.
• Feature-Policy wurde durch Permissions-Policy ersetzt.

Server und X-Powered-By nennen Ihre Software, manchmal samt Versionsnummer. OWASP empfiehlt, sie zu entfernen oder nichtssagend zu machen, nennt das im eigenen Testleitfaden aber Security through Obscurity, und MDN hält aktuelle Patches für wichtiger. Entfernen Sie die Versionsnummern (in nginx entfernt server_tokens off; die Version, nicht den Header) und stecken Sie die Mühe lieber in Updates.

7. Basiskonfiguration zum Übernehmen: nginx, Apache und statische Hosts

Diese Basis für nginx setzt die risikoarmen Header, startet HSTS und CSP in ihrer Teststufe und leitet HTTP beim selben Host auf HTTPS weiter. Der Parameter always hängt die Header auch an Fehlerantworten an.

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate und ssl_certificate_key gehören hierher
    server_tokens off;

    add_header Strict-Transport-Security "max-age=300" 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;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'" always;
}

Zwei dokumentierte Eigenheiten des nginx-Header-Moduls erklären viele fehlende Header. Ohne always gilt add_header nur für die Statuscodes 200, 201, 204, 206, 301, 302, 303, 304, 307 und 308; 404- und 500-Seiten werden also ohne die Header ausgeliefert. Und add_header-Direktiven werden von der umgebenden Ebene nur geerbt, wenn die aktuelle Ebene selbst keine definiert: Ein einziges add_header in einem location-Block lässt dort alle Security-Header der Server-Ebene wegfallen. Wiederholen Sie die Header, binden Sie eine gemeinsame Datei per include ein oder nutzen Sie ab nginx 1.29.3 add_header_inherit merge;.

Auf Apache, etwa bei Shared Hosting ohne Zugriff auf die Serverkonfiguration, setzen Sie dieselben Header mit mod_headers in der .htaccess:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'"

Mit der Bedingung always landen die Header laut der Apache-Dokumentation auch in Fehlerantworten und lokal erzeugten Weiterleitungen; ohne sie gelten sie nur für erfolgreiche Antworten. Apache führt Header mit und ohne always in getrennten Tabellen; werden beide genutzt, kann ein Header doppelt erscheinen, wie das OWASP HTTP Headers Cheat Sheet anmerkt. Kontrollieren Sie das Ergebnis deshalb mit curl, besonders wenn auch die Anwendung oder ein CMS-Plugin Security-Header setzt.

Statische Hosts wie Cloudflare Pages und Netlify lesen eine Datei _headers, die mit der Website ausgeliefert wird. Dieses Beispiel folgt dem dokumentierten Format von Cloudflare, das auch Netlify verwendet:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  X-Frame-Options: SAMEORIGIN
  Content-Security-Policy-Report-Only: default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'

Beachten Sie die Grenzen. Cloudflare Pages wendet die Datei nicht auf Antworten an, die Pages Functions erzeugen, erlaubt bis zu 100 Header-Regeln mit höchstens 2.000 Zeichen pro Zeile und verbindet die Werte mit einem Komma, wenn derselbe Header zweimal greift. Netlify wendet eigene Header nur auf Dateien an, die es selbst ausliefert, nicht auf weitergeleitete (Proxy-)Inhalte, Functions, Edge Functions oder serverseitig gerenderte Seiten; diese Antworten müssen ihre Header selbst setzen. HSTS fehlt im Apache- und im _headers-Beispiel absichtlich: Prüfen Sie zuerst mit curl, was Hoster oder Plattform bereits senden, bevor Sie den Header ergänzen.

8. Schrittweise einführen und die typischen Fehler vermeiden

1. Ergänzen Sie nosniff, Referrer-Policy, Permissions-Policy und Frame-Schutz und testen Sie danach Login, Checkout und eingebettete Widgets.
2. Senden Sie den CSP-Entwurf als Content-Security-Policy-Report-Only. Blockiert wird nichts; Verstöße erscheinen in der Browserkonsole und, falls die Richtlinie einen Reporting-Endpunkt nennt, auch dort. Gehen Sie die wichtigsten Abläufe durch, auch Seiten hinter dem Login, und passen Sie die Richtlinie an.
3. Starten Sie HSTS mit einem kurzen max-age und erhöhen Sie ihn stufenweise.
4. Schalten Sie die CSP scharf. Parallel kann eine strengere Report-Only-Richtlinie die nächste Verschärfung testen.
5. Wiederholen Sie die curl-Prüfungen nach jeder Änderung an Server, CDN oder Framework.

Typische Fehler:

• Header nur auf einem Teil der Antworten. Die Startseite hat sie, die 404-Seite, die API, statische Dateien oder eine separat ausgelieferte Login-Seite nicht.
• Host und Schema in einer einzigen Weiterleitung wechseln. Leitet http://example.com direkt auf https://www.example.com weiter, erhält der Browser nie HSTS für example.com. Leiten Sie zuerst beim selben Host auf HTTPS weiter, senden Sie HSTS mit dieser HTTPS-Antwort und leiten Sie erst danach auf www um.
• Eine andere Ebene überschreibt die Header. Ein CDN oder Proxy kann Header hinzufügen, ersetzen, entfernen oder verdoppeln, ebenso ein CMS-Plugin, das eigene Header setzt. Legen Sie fest, welche Ebene für welchen Header zuständig ist, und prüfen Sie das Ergebnis mit curl.
• Eine CSP, die alles erlaubt. Eine Richtlinie, die mit 'unsafe-inline', 'unsafe-eval' oder * aufgefüllt wurde, um Fehlermeldungen loszuwerden, besteht eine Prüfung auf Vorhandensein, blockiert aber kaum etwas.
• includeSubDomains zu früh. Eine vergessene Subdomain, die nur über HTTP funktioniert, ist für Browser, die die Richtlinie gespeichert haben, nicht mehr erreichbar.

Header sind nur eine von mehreren Schutzschichten. Die Website-Launch-Checkliste stellt sie neben DNS, TLS und Weiterleitungen, und der Leitfaden Website-Sicherheit prüfen behandelt Login, Berechtigungen und eine wiederholbare Prüfroutine.

9. Wie der kostenlose Snapshot von Sitelemetry Header prüft

Der kostenlose Snapshot führt ohne Anmeldung acht passive Prüfungen an einem öffentlichen Origin aus; eine davon liest die HTTP-Security-Header. Er ist kein Penetrationstest und nicht das Audit mit sechs Bereichen.

• Er ruft die Startseite des eingegebenen Origins ab (Pfade und Query-Strings werden verworfen), folgt bis zu fünf Weiterleitungen und bewertet die letzte Antwort. Weitere Seiten fragt er nicht ab.
• Er prüft vor allem, ob Header vorhanden sind. Eine fehlende CSP, fehlendes HSTS bei einem HTTPS-Ziel, fehlender Frame-Schutz und Access-Control-Allow-Origin: * gelten als mittleres Risiko. Ein X-Content-Type-Options-Header, der fehlt oder nicht genau nosniff lautet, eine fehlende Referrer-Policy und jeder Server- oder X-Powered-By-Header gelten als niedriges Risiko; auch Server: nginx ohne Version löst also ein Signal aus. Cookies, die in dieser Antwort ohne HttpOnly oder bei HTTPS ohne Secure gesetzt werden, gelten als mittleres Risiko; SameSite wird nicht geprüft.
• Eine separate Härtungsnote (im Ergebnis „Härtung“, A bis F) bewertet die vorhandenen Header zusammen mit dem TLS-Ergebnis und gewichtet eine CSP geringer, wenn sie 'unsafe-inline' erlaubt (bei Skripten auch 'unsafe-eval'). Permissions-Policy und COOP zählen nur in dieser Note.
• Die Prüfung der HTTPS-Weiterleitung hängt davon ab, was Sie eingeben. Bei einer Domain ohne Schema oder einer https://-Adresse meldet sie ein HSTS-max-age unter 180 Tagen als niedriges Risiko, was während einer stufenweisen Einführung zu erwarten ist, und sucht im HTML der Seite nach http://-Verweisen (Mixed Content); die Weiterleitung von HTTP auf HTTPS testet sie dann nicht. Die Weiterleitung wird nur geprüft, wenn Sie die http://-Adresse eingeben; dieser Durchlauf überspringt die TLS-Prüfung und meldet fehlendes HSTS nicht.

Das Ergebnis zeigt einen Score, die Härtungsnote, die Zahl der Risikosignale und der bestandenen Prüfungen sowie bis zu drei Signale, Risiken zuerst. Es listet nicht jeden Header mit seinem Wert auf. Dafür und für die Antworten, die der Snapshot nicht abruft, nutzen Sie DevTools oder curl.