Die Sicherheitsheader, die die meisten Websites immer noch überspringen: Daten aus 49 echten Audits

Für diesen Bericht haben wir 6 Sicherheits-Header aus der endgültigen Startseiten-Antwort jeder geprüften Website gelesen, nach Weiterleitungen. Ein Header, der nur auf einem Hop vor der Weiterleitung gesendet wird, zählt nicht, weil der Browser ihn nie auf die Seite anwendet. Die Frage ist absichtlich eng: trug die Antwort überhaupt den Header.

Anhand von 49 geprüften Websites zwischen Mai 23 und August 31, 2026 ist die Antwort in der Regel nein. Permissions-Policy fehlt bei 69% von ihnen, Referrer-Policy bei 65%, Content-Security-Policy bei 61%, X-Frame-Options bei 51%, X-Content-Type-Options bei 43% und Strict-Transport-Security – das am häufigsten genutzte der 6 – bei 41%.

Methodik: neuestes abgeschlossene Audit-Snapshot pro Domain aus unserem aktuellen Checkset, ungefähr Mai 23 – August 31, 2026, 49 unterschiedliche Domains, anonymisiert. Jeder Prozentsatz ist der Anteil der Websites, deren Startseitenantwort diesen Header nicht trug. Die Stichprobe ist selbstausgewählt – Eigentümer, die ein Audit durchgeführt haben – und neigt zu kleinen und mittelgroßen Websites, was wahrscheinlich die Header-Adoption im gesamten Web unterschätzt, da große Plattformen diese am Rand setzen. Behandeln Sie die Anteile als richtungsweisend für den langen Schwanz.

Diese Zahlen zählen Vorhandensein, nicht Qualität

Präzision bei der Messung ist hier wichtig, weil sie die Obergrenze dafür setzt, was diese Zahlen behaupten können.

Die Zahlen beschreiben 1 Antwort pro Website: die Startseite, nach Weiterleitungen. Vorhandensein bedeutet einen nicht-leeren Wert, und nicht mehr. Ein Strict-Transport-Security-Header, dessen max-age 1 Sekunde beträgt, gilt als vorhanden, und ebenso eine Content-Security-Policy, die so permissiv ist, dass alles erlaubt wird. Vorhandensein sagt nichts darüber aus, ob die Richtlinie gut konstruiert ist.

Das sieht wie ein schwacher Maßstab aus, bis man bedenkt, was er misst. Ein Header mit irgendeinem Wert ist Beweis dafür, dass ein Mensch einmal eine Serverkonfiguration, eine CDN Regel oder eine Middleware-Datei geöffnet und eine Direktive eingegeben hat. Die Messung ist ein Test, ob die Konfigurationsschicht einer Website jemals absichtlich berührt wurde – weshalb die Fehlerraten die interessante Seite sind, nicht die Bestehensraten.

Zwei Details entscheiden darüber, ob ein Header, den Sie bereits ausliefern, tatsächlich etwas schützt:

• Report-only CSP erzwingt nichts. Content-Security-Policy-Report-Only protokolliert Verstöße, ohne sie zu blockieren. Das ist der richtige Einstieg, aber bis der erzwingende Content-Security-Policy-Header ausgeliefert wird, schützt die Richtlinie nichts.
• frame-ancestors und X-Frame-Options erreichen unterschiedliche Clients. Eine CSP-frame-ancestors-Direktive ist die bessere Kontrolle, und ältere Clients lesen nur den Legacy-Header X-Frame-Options. Liefern Sie beide aus.

Adoption verfolgt, wie alt ein Header ist, nicht wie hart er ist

Die Reihenfolge der Fehlerraten ist annähernd umgekehrt chronologisch. HSTS, das älteste der 6 und in jedem wichtigen CDN-Dashboard zu einem Schalter reduziert, ist das am weitesten verbreitete. X-Content-Type-Options und X-Frame-Options, beide Anbieter-Konventionen, die lange vor ihren formellen Nachfolgern existierten, liegen in der Mitte. Referrer-Policy und Permissions-Policy, die beiden neuesten, sind die beiden am wenigsten verbreiteten — und Permissions-Policy, die kein gemeinsamer Host für Sie setzt, ist zuletzt.

Keiner von ihnen ist in ingenieurtechnischen Begriffen härter als die anderen. 5 von 6 sind eine statische Zeile in einem Serverblock, eine CDN-Regel oder eine Edge-Middleware-Datei, ohne Anwendungsänderungen und ohne Verhaltensrisiko. Was sie trennt, ist, wie lange sie Zeit hatten, Standards zu akkumulieren, und wie viele Blogposts, Checklisten und Framework-Vorlagen sie aufgenommen haben. Wir sahen die gleiche Form, als wir jeden fehlgeschlagenen Check in unserer Audit-Historie rangierten: Antwort-Header dominierten die Spitze der Liste, über Canonicalisierung, Rendering und Performance. Diese Rangliste umfasste ein anderes Fenster, eine andere Stichprobe und ein früheres Checkset, sodass die beiden Prozentwerte keine Trendlinie sind — aber die Position der Header an der Spitze beider ist die dauerhafte Erkenntnis.

Der andere strukturelle Grund ist Unsichtbarkeit. Ein fehlender Header ändert nichts auf dem Bildschirm. Kein CMS warnt Sie, kein Build schlägt fehl, kein Dashboard wird rot. Das Fehlen ist nur für etwas beobachtbar, das rohe Antworten inspiziert — was genau ein Audit, der Sicherheitszustand eines Browsers und ein zunehmender Anteil automatisierter Leser tun. Es ist die gleiche Asymmetrie, die wir in Render Parity gefunden haben: was Menschen in einem Browser sehen und was Maschinen über HTTP erhalten, haben sich leise auseinanderentwickelt.

Was jeder Header schützt

Strict-Transport-Security weist den Browser an, für Ihre Domain für einen angegebenen Zeitraum keine Klartext-HTTP zu akzeptieren, was das Redirect-Fenster schließt, das ein Angreifer im Netzwerk übernehmen kann, bevor Ihr http:// → https://-Redirect einsetzt. Es ist auch der einzige Header auf der Liste, der eine Verpflichtung trägt: Browser honorieren die max-age selbst dann, wenn Sie später die HTTPS brechen. Beginnen Sie kurz, bestätigen Sie, dass jedes Subdomain und Asset sauber über TLS bereitgestellt wird, und erweitern Sie dann.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Content-Security-Policy begrenzt, wo Skripte, Styles, Frames und Verbindungen herkommen dürfen. Es ist der einzige Header hier, der ein Ereignis enthält, anstatt eine Kategorie davon zu verhindern: wenn ein Tag-Manager kompromittiert wird oder Benutzereingaben das DOM erreichen, entscheidet CSP, ob das injizierte Skript ausgeführt werden kann oder einen Server erreicht, den es wählt. Es ist auch der einzige, der eine funktionierende Seite zerstören kann, weshalb er am Ende der untenstehenden Sequenz steht.

Content-Security-Policy-Report-Only: default-src 'self'

X-Frame-Options gibt an, ob andere Ursprünge Ihre Seiten in einen Frame einbetten dürfen. Ohne ihn kann Ihre Oberfläche unter einer transparenten Überlagerung auf einer Angreiferseite eingebettet und von Benutzern angeklickt werden, die glauben, sie wären auf Ihrer Seite. Moderne CSP drückt dies besser mit frame-ancestors; liefern Sie beide, da ältere Clients nur den Legacy-Header lesen.

X-Frame-Options: DENY

X-Content-Type-Options verhindert, dass Browser den Typ einer Antwort raten, wenn der deklarierte Content-Type falsch aussieht. Sniffing ist, wie eine hochgeladene Datei, die Sie als Text bereitstellen, als Skript ausgeführt werden kann. Der Header hat genau 1 gültigen Wert.

X-Content-Type-Options: nosniff

Referrer-Policy regelt, wie viel des aktuellen URL zu Dritten bei ausgehenden Klicks und Subressourcen-Loads gelangt. Ihre URLs tragen Kampagnenparameter, interne Suchanfragen, Kontoinformationen und manchmal Tokens, und jedes Analyse-Pixel und jeder Font CDN auf der Seite ist ein Empfänger. Hauptbrowser haben sich auf einen vernünftigen Standard geeinigt, aber ein Standard ist eine Entscheidung, die der User Agent für Sie trifft und variiert je nach Client; das Senden des Headers macht Ihre Richtlinie explizit und lässt eine Seite, die sensible URLs verarbeitet, etwas Strengeres wählen, wie same-origin.

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy entscheidet, welche Browser-Fähigkeiten Ihr Dokument und seine eingebetteten Frames anfordern dürfen — Kamera, Mikrofon, Geolokalisierung und die restliche Liste der leistungsfähigen Features. Fehlt der Header, ist alles, was Sie nicht deaktiviert haben, jedem Skript auf der Seite verfügbar, einschließlich Drittanbieter-Tags, die Sie nicht geschrieben haben. Verweigern Sie, was Sie nicht benutzen.

Permissions-Policy: camera=(), microphone=(), geolocation=()

Liefern Sie zuerst die 4 One-Liner, dann verbringen Sie einen Nachmittag mit CSP

Schutzwert und Bereitstellungsrisiko stimmen sich nicht über genau 1 Header überein, und die Reihenfolge der Behebung löst die Meinungsverschiedenheit zugunsten des Versands.

graph TD
    A[Lesen Sie Ihre eigenen Antwort-Header] --> B[Deploy 1: HSTS mit kurzer max-age]
    B --> C[Deploy 2: nosniff, Referrer-Policy, Permissions-Policy, X-Frame-Options]
    C --> D[Erweitern Sie die HSTS max-age, sobald TLS überall bestätigt ist]
    D --> E[CSP im Nur-Bericht-Modus]
    E --> F{Verstoßberichte sauber?}
    F -->|Nein| G[Quellen anpassen, Nur-Bericht beibehalten]
    G --> F
    F -->|Ja| H[CSP erzwingen, frame-ancestors hinzufügen]

Bereitstellung 1 — HSTS, kurz. Hoher Schutzwert, und nahezu kein Risiko, wenn Ihre Seite bereits HTTPS überall bereitstellt. Setzen Sie zunächst ein bescheidenes max-age, damit ein TLS-Problem bei einem vergessenen Subdomain wiederherstellbar bleibt.

Bereitstellung 2 — die 4 statischen Zeilen zusammen. nosniff, Referrer-Policy, Permissions-Policy und X-Frame-Options sind statische Werte ohne Anwendungsabhängigkeit. Sie sind 4 der 6 Header und bei diesen Fehlerraten fehlt bei den meisten Seiten die Mehrheit dessen, was ein durchschnittlicher Site fehlt. Es gibt keinen Grund, sie separat zu schichten.

Dann HSTS erweitern, sobald Sie bestätigt haben, dass jeder Host unter der Domain sauber über TLS bereitstellt.

Zuletzt — CSP, im Nur-Bericht-Modus. Deploy Content-Security-Policy-Report-Only, sammeln Sie Verstöße aus echtem Traffic und listen Sie die Skript- und Verbindungsquellen auf, auf die Sie tatsächlich angewiesen sind. Nur dann die Header auf erzwingen umstellen und frame-ancestors neben Ihrer X-Frame-Options-Zeile hinzufügen. Höchster Aufwand, zuletzt in der Sequenz, weil es das einzige Element auf der Liste ist, das eine funktionierende Seite herunterziehen kann.

Lesen Sie Ihre eigenen Header in 1 Befehl

Die gesamte Messung ist von einem Terminal aus reproduzierbar. Folgen Sie Weiterleitungen, denn die endgültige Antwort ist diejenige, die der Browser anwendet:

curl -sSL -o /dev/null -D - https://example.com/ \
  | grep -iE 'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'

Jede Zeile, die nicht zurückkommt, ist ein Header, den Ihre Homepage nicht sendet. Alle 6 die zurückkommen, bedeutet, dass die Präsenzleiste gelöscht ist und die nächste Frage — ob die Richtlinien selbst gut sind — es wert ist zu stellen. Eine kostenpflichtige SEOReport-Diagnose listet jeden fehlenden Header mit dem Wert, der ihn löst.

Die Header in diesem Datensatz fehlen nicht, weil sie schwierig oder umstritten sind. Sie fehlen, weil nichts im gewöhnlichen Leben einer Website jemals ihr Fehlen sichtbar macht: kein Fehler, keine visuelle Änderung, kein fehlender Build. Die Seiten, die bestehen, sind die, bei denen jemand einmal gesucht hat — und diese einzelne Bereitstellung ist noch immer für die Mehrheit verfügbar, die nicht.