Erweiterte Security Header: Wirkung und Reifegrad

Welche Ergänzung zu welcher Aufgabe passt

Die Grundlagen zu HSTS, CSP und COOP/COEP/CORP bleiben eigenständige Themen. Hier geht es um die Abgrenzung und den passenden zusätzlichen Einsatz.

Origin-Agent-Cluster: Gruppierung statt Prozessgarantie

Origin-Agent-Cluster: ?1

?1 ist der boolesche Wahr-Wert eines Structured Field. Der aktuelle grundlegende RFC hierfür ist RFC 9651, der RFC 8941 abgelöst hat. Der HTML-Standard erlaubt einem Dokument in einem sicheren Kontext, mit diesem Header ein nach Origin gruppiertes Agent Cluster anzufordern. Eine Origin umfasst Schema, Host und Port. HTML-Standard, RFC 9651

Bei aktivem Origin-Keying kann document.domain die Same-Origin-Grenze nicht mehr lockern. Auch der Austausch eines WebAssembly.Module mit einem Dokument anderer Origin ist dadurch eingeschränkt. Das kann alte Anwendungen treffen, die etwa app.example.com und login.example.com über document.domain zusammengeführt haben. Planen Sie dafür gleiche Origins oder eine klar begrenzte Nachrichtenkommunikation mit geprüfter Absender-Origin und geprüftem Nachrichtenformat.

Der Browser bestimmt weiterhin die konkreten Prozesse und Threads. Weder ein gesetztes ?1 noch window.originAgentCluster === true beweist einen eigenen Prozess oder vollständigen Schutz gegen Spectre. Umgekehrt beweist ein fehlender Header nicht, dass zwei Subdomains denselben Prozess teilen. Browserdefaults können Origin-Keying bereits einschalten. Chrome führte einen solchen Default ab Version 115 ein; ältere Ausweichmöglichkeiten und Unternehmensrichtlinien sind kein zukunftsfestes Architekturkonzept. Chrome zu document.domain

Setzen Sie den gewählten Vertrag konsistent auf den betroffenen Dokumenten. Innerhalb einer Browsing-Context-Gruppe beeinflusst auch die bereits geladene Historie derselben Origin die Zuordnung; ein später hinzugefügter Header ordnet bestehende Dokumente nicht beliebig neu. Zur Prüfung gehören deshalb frische Kontexte und die wirklichen Frame-/Fensterabläufe. In unserer lokalen Chromium-147-Probe war Origin-Keying schon ohne Header aktiv. ?1 verhinderte die alte DOM-Zusammenführung; die ausdrücklich erprobte Chromium-Variante ?0 erlaubte sie. Das ist eine Beobachtung dieses Browsers, keine allgemeine Empfehlung für ?0.

Fetch Metadata: Informationen für serverseitige Entscheidungen

Fetch Metadata besteht aus Anfrageheadern des Browsers. Sie sind keine Antwortheader, die man einfach in die Serverkonfiguration kopiert:

Die Anwendung kann damit beispielsweise sensible Endpunkte gegen unerwartete, von fremden Seiten ausgelöste Browseranfragen abschirmen. Eine pauschale Sperre sämtlicher cross-site-Anfragen würde aber auch normale Links, eingebettete Ressourcen und manche Login-Rückwege beschädigen. Entscheiden Sie nach Route, Methode und Zweck. Ein absichtlich öffentlicher Bildabruf braucht andere Regeln als eine Änderung im Kundenkonto. same-site bedeutet zudem nicht zwangsläufig, dass jede beteiligte Subdomain vertrauenswürdig ist.

Normales Seiten-JavaScript kann diese Sec--Header nicht frei vorgeben. Beliebige HTTP-Clients außerhalb des Browsers können sie jedoch nachbilden; sie sind keine Benutzeridentität und kein Ersatz für Authentifizierung, Berechtigungsprüfung oder ein passendes CSRF-Konzept. Fehlende Header benötigen eine bewusste Behandlung für alte Clients, Bots und nicht browserbasierte Integrationen. Ein Proxy darf die Auswertung nicht durch unkontrolliertes Überschreiben entwerten.

Beginnen Sie mit einer begrenzten Beobachtung der echten Abrufwege und führen Sie Regeln pro Endpunkt ein. Hängt die Antwort von Fetch Metadata ab, muss die Cache-Konfiguration diese Auswahl berücksichtigen, gegebenenfalls mit passenden Vary-Feldern. Andernfalls kann ein Shared Cache eine für einen anderen Kontext erzeugte Antwort wiederverwenden. Fetch-Metadata-Entwurf, §§ 2, 4, 5

Integrity-Policy: SRI-Metadaten verbindlich machen

Subresource Integrity prüft eine Ressource anhand des angegebenen Hashwerts. Integrity-Policy ergänzt dies um die Anforderung, dass bestimmte Ressourcen überhaupt geeignete Integritätsmetadaten besitzen. Ein begrenztes Beispiel für die Beobachtungsphase lautet:

Reporting-Endpoints: integrity="https://reports.example/integrity"
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity)

Die Platzhalterdomain ist vor Verwendung durch den eigenen eingerichteten Empfänger zu ersetzen. Die Report-Only-Variante blockiert aufgrund dieser Richtlinie nicht. Erst nach Prüfung des Ressourcenbestands, der Meldungen und der Funktionswege kommt eine durchgesetzte Integrity-Policy infrage. Berichtsunterstützung und Empfang sind zusätzlich zu prüfen; dazu dient der Reporting-Artikel.

Die Richtlinie betrifft externe Ressourcenanfragen, keine allgemeine Prüfung des gesamten JavaScript-Inhalts. Ein klassisches Skript kann trotz richtigem Hash blockiert werden, wenn es im Modus no-cors angefordert wird. Bei einem <script> kann deshalb crossorigin="anonymous" auch bei gleicher Origin nötig sein, um den passenden Modus zu verwenden. Bei fremder Origin muss außerdem deren CORS-Antwort passen. Das bestätigte unsere begrenzte Chromium-Probe: fehlende Metadaten und der no-cors-Fall wurden blockiert, der Fall mit passendem Hash und CORS-Modus lief.

Der SRI-Entwurf führt die Ziele script und style; daraus folgt keine identische Unterstützung. Die am 27. September 2026 gelesenen Browserdaten nennen für den Header Chrome 138, Firefox 145 und Safari 26, bei Firefox jedoch ohne Auswertung der Reporting-Endpunkte. Für style verzeichnen sie keine reguläre Unterstützung in Chrome und Safari und nur eine aktivierbare Firefox-Option. Kopieren Sie deshalb nicht ungeprüft eine allgemeine Richtlinie für Skripte und Styles. SRI-Entwurf, § 3.8, Browserdaten

Document-Isolation-Policy: gezielte Erprobung statt allgemeiner Vorgabe

Document-Isolation-Policy beschreibt einen weiteren Weg zur Cross-Origin-Isolation eines Dokuments. Die ausgewertete WICG-Spezifikation ist ein Community-Entwurf, kein abgeschlossener W3C-Standard. Google dokumentiert die Einführung ab Chrome 137 auf Desktop. Eine dort genannte Absicht für Android ist noch kein Nachweis für Ihre konkrete mobile Zielumgebung. Entwurf, Chrome-Einführung

Die Werte isolate-and-require-corp und isolate-and-credentialless legen unterschiedliche Bedingungen für fremde Ressourcen fest. Der erste verlangt passende Freigaben über CORS oder CORP. Der zweite verändert insbesondere den Umgang mit Credentials bei fremden no-cors-Unterressourcen. Im Unterschied zum klassischen COOP/COEP-Weg soll die Isolation dokumentbezogen möglich sein, ohne dieselben Anforderungen an sämtliche Kindframes und Popup-Beziehungen.

Das kann für eine Anwendung interessant sein, die isolationsabhängige Funktionen benötigt und deren Einbettungen den bisherigen Weg erschweren. Es rechtfertigt keinen pauschalen Austausch einer funktionierenden COOP/COEP-Konfiguration. Prüfen Sie self.crossOriginIsolated, Ressourcen, Fensterkommunikation und gewünschte Funktionen in den tatsächlichen Zielumgebungen. Ein bloß vorhandener Header genügt nicht. Unsere Desktop-Chromium-Probe bestätigte Isolation und das unterschiedliche Laden eines fremden Bildes für die beiden Werte; sie prüfte keine mobile Plattform und keine vollständige Anwendung.

HTTPS-Redirects und Hostvarianten richtig ordnen

Für dauerhaft umgezogene Adressen sind 301 und 308 die permanenten Weiterleitungen. 302 und 307 beschreiben vorübergehende Weiterleitungen. Bei 301 und 302 darf ein Client eine POST-Anfrage historisch bedingt in GET ändern; 307 und 308 erhalten die Methode. Wählen Sie deshalb nach Dauerhaftigkeit und benötigtem Methodenverhalten, nicht nach einer pauschalen Sicherheitsrangliste. RFC 9110, § 15.4

Wenn die endgültige kanonische Adresse feststeht, vermeiden Sie unnötige Zwischenschritte:

Ein 301 beseitigt dieses erste HTTP-Risiko nicht. Auch die Behauptung „302 wird nie gecacht“ ist falsch; Cache-Regeln und Antwortinformationen beeinflussen die Wiederverwendung. Bereits bekanntes oder zutreffend vorgeladenes HSTS kann ein HTTP-Ziel vor dem Netzabruf zu HTTPS hochstufen. Es ersetzt aber nicht beliebige Hostnormalisierung, und eine erstmals über HTTP empfangene Umleitung kann dem Browser kein vertrauenswürdiges HSTS vermitteln.

Ob www.example.com oder example.com die Hauptadresse ist, hängt von Ihrer Architektur ab. Für nicht existierende oder bewusst getrennte Hosts gibt es nichts pauschal zusammenzuführen. Bei tatsächlichen Aliasadressen sollten Redirects, interne Links und Canonical-Angaben übereinstimmen; Pfade und erforderliche Parameter müssen erhalten bleiben. Google behandelt permanente Redirects als Canonical-Signal. Daraus folgt keine garantierte Rankingsteigerung und keine allgemeine Bevorzugung von non-www. Google zu Redirects

Historische Filter und Softwareangaben aufräumen

Chrome entfernte seinen XSS Auditor bereits mit Version 78. Das ist keine gemeinsame Versionsgrenze für alle Browser. Gegen XSS helfen vor allem sichere Datenverarbeitung, kontextgerechte Ausgabe und geeignete Browserrichtlinien wie CSP. Das bloße Ersetzen eines Headernamens beseitigt keine Anwendungslücke. Chromium zum historischen XSS Auditor

Befund, Schutzwirkung und Compliance auseinanderhalten

Der Web Security Check berücksichtigt im geprüften Stand den sichtbaren OAC-Wert und beobachtete Redirects. HTTP-/HTTPS-Einstieg und Hostvariante werden über begrenzte Nebenabrufe untersucht. Das ist keine Prüfung aller Pfade, aller Browserdefaults oder der serverseitigen Fetch-Metadata-Regeln. Die hier beschriebenen neueren Richtlinien werden nicht dadurch automatisch zu vollständig geprüften Scannerfunktionen.

Ein Header-Scan weist weder eine vollständige Sicherheitsarchitektur noch allgemeine Rechtskonformität nach. Entscheidend sind die betroffene Anwendung, die tatsächliche Wirkung und die dokumentierte Entscheidung. Ein fehlender zusätzlicher Header allein begründet keine allgemeine gesetzliche Pflicht zu seiner Einführung.