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

Jedes Audit, das wir durchführen, liest die Antwortheader der Startseite. 6 von ihnen tragen ein Bestehen-oder-Fehlschlagen-Urteil; report-only CSP und das Cross-Origin-Isolation-Paar werden im Kontext gemeldet und zählen nie als Fehler. Das Lesen erfolgt bei der einfachen HTTP-Abfrage – die gleiche Aufnahme, die ein KI-Crawler erhält – und bei der endgültigen Antwort nach Weiterleitungen, sodass eine Website, die ihre Header nur beim Vorwärts-Weiterleitungs-Hop setzt, keine Anerkennung dafür erhält. Die Frage, die die Engine stellt, 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 abgeschlossenen 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 die Header-Adoption im gesamten Web wahrscheinlich unterschätzt, da große Plattformen diese am Rand setzen. Behandle die Anteile als richtungsweisend für den langen Schwanz.

Die Prüfung fragt, ob der Header existiert, nicht, ob er gut ist

Präzision bei der Messung ist hier wichtig, weil sie die Obergrenze dafür setzt, was diese Zahlen behaupten können. Die Engine liest die Startseite nur – ein URL, eine Antwort – und nimmt die Header-Werte aus der einfachen-HTTP-Aufnahme, wenn diese verfügbar ist, fällt zurück auf die andere Startseitenaufnahme, wenn sie nicht verfügbar ist. Vorhandensein bedeutet ein nicht-leerer Wert. Es gibt keine Bewertung der Direktiven: ein Strict-Transport-Security dessen max-age 1 Sekunde beträgt, besteht, und ebenso ein Content-Security-Policy, der so permissiv ist, dass er alles zulässt. Nichts über ein Bestehen-Urteil sagt aus, dass die Richtlinie gut konstruiert ist. Das sieht aus wie ein schwacher Maßstab, 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 Prüfung ist ein Test, ob die Konfigurationsschicht einer Website jemals absichtlich berührt wurde – weshalb die Fehlerraten die interessante Seite sind, nicht die Bestehensraten. Schwere wird pro Header zugewiesen, nicht einheitlich. Strict-Transport-Security und Content-Security-Policy scheitern bei hoher Schwere. X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy scheitern bei mittlerer. Cross-origin isolation, das COOP- und COEP-Paar, ist nur informativ — es wird bestanden, wenn einer der Header vorhanden ist, und ansonsten wird ein Informationsurteil ausgegeben, niemals ein Fehlschlag, weil diese Header fortgeschrittene Browserfunktionen gate, statt Basisverteidigungen. Zwei Verhaltensweisen sind es wert, bevor Sie Ihren eigenen Bericht lesen:

• Report-only CSP erfüllt die CSP-Prüfung nicht. Der Engine schaut speziell auf Content-Security-Policy. Eine Seite, die nur Content-Security-Policy-Report-Only ausführt, besteht die Durchsetzungsprüfung nicht und erhält ein separates Informationsurteil, das besagt, dass Verstöße protokolliert, aber nicht blockiert werden. Dieses Urteil existiert nur, wenn einer der beiden CSP-Header vorhanden ist.
• frame-ancestors erfüllt die X-Frame-Options-Prüfung nicht. Der Engine liest den X-Frame-Options-Header selbst. Eine moderne CSP mit einer frame-ancestors-Direktive ist die bessere Kontrolle, und eine Seite, die sie ausliefert und dabei den Legacy-Header entfernt, wird die Prüfung trotzdem fehlschlagen sehen.

Es gibt auch eine Plattformanpassung im Code. Wenn die Antwort von Vercel kommt und die Seite Vercel's BotID-Skript lädt, schlägt ein fehlender CSP trotzdem fehl, aber bei mittlerer statt hoher Schwere, mit einer Notiz, die erklärt, dass BotID Inline-Skript-Berechtigungen benötigt, die die strenge CSP-Durchsetzung bekämpfen. Eine Seite kann die Einschränkung absichtlich dokumentieren, indem sie einen HTML-Kommentar wie <!-- seoreport-ignore: vercel-botid-csp --> im ersten 1 KB der Homepage platziert; wenn der Grundname CSP oder BotID ist, fällt die Prüfung auf ein Informationsurteil statt auf einen Fehlschlag. Dies ist die einzige Ausweichmöglichkeit in der Familie, und sie existiert, weil eine echte Plattformbeschränkung nicht als Nachlässigkeit gelesen werden sollte.

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 auf einen Schalter in jedem großen CDN-Dashboard reduzierbar, ist das am weitesten verbreitete. X-Content-Type-Options und X-Frame-Options, beide lange vor ihren formellen Nachfolgern existierende Anbieter-Konventionen, liegen in der Mitte. Referrer-Policy und Permissions-Policy, die beiden neuesten, sind die beiden am wenigsten verbreiteten — und Permissions-Policy, das 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 einzige 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 ausgelöst wird. Es ist auch der einzige Header auf der Liste, der eine Verpflichtung trägt: Browser respektieren die max-age auch dann, wenn Sie später die HTTPS brechen. Beginnen Sie kurz, bestätigen Sie, dass jede Subdomain und jedes Asset sauber über TLS bereitgestellt werden, 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 Seite eines Angreifers 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 der Legacy-Header das ist, was ältere Clients und unsere eigene Prüfung 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, anstatt. Der Header hat genau 1 gültigen Wert.

X-Content-Type-Options: nosniff

Referrer-Policy regelt, wie viel der aktuellen URL zu Dritten bei ausgehenden Klicks und Subressourcenladungen gelangt. Ihre URLs tragen Kampagnenparameter, interne Suchanfragen, Kontoinformationen und manchmal Tokens, und jedes Analyse-Pixel und jede Schriftart 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 je nach Client variiert; das Senden des Headers macht Ihre Richtlinie explizit und ermöglicht einer Seite, die sensible URLs verarbeitet, etwas Strengeres zu 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 der Rest der leistungsstarken-Funktionen-Liste. 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=()

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

Engine-Schwere und Bereitstellungsrisiko stimmen sich nicht über genau 1 Header überein, und die Reihenfolge der Korrektur löst die Meinungsverschiedenheit zugunsten des Versands auf.

Bereitstellung 1 — HSTS, kurz. Höchste Schwere, 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. Bereitstellen 2 — die 4 mittleren Schweregrad‑Zeilen zusammen. nosniff, Referrer-Policy, Permissions-Policy und X-Frame-Options sind statische Werte ohne Anwendungsabhängigkeit. Sie sind 4 der 6 Prüfungen und bei diesen Fehlerraten fehlt bei der Mehrheit einer durchschnittlichen Seite die Mehrheit dessen, was fehlt. Es gibt keinen Grund, sie separat zu schalten. 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öchste Schwere, höchste Anstrengung, 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, weil das der Motor tut:

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 Check, bei dem Ihre Homepage fehlschlägt. 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, gestellt zu werden. Unser kostenloser Bericht führt die gleiche Leseoperation bei jeder Prüfung durch und 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.