COOP, COEP und CORP: Fenster und Ressourcen gezielt trennen

Welche zusätzliche Grenze wird gebraucht?

Eine Origin umfasst Schema, Host und Port. Verschiedene Unterdomains sind daher unterschiedliche Origins. Die Same-Origin-Policy beschränkt bereits bestimmte Zugriffe zwischen ihnen. Zusätzliche Mechanismen können Fensterbeziehungen trennen oder verhindern, dass bestimmte fremde Antworten in einen Dokumentkontext gelangen. Eine Motivation sind Seitenkanalangriffe wie Spectre; die Header beseitigen nicht die zugrunde liegende Klasse aller Seitenkanäle.

Für eine gewöhnliche Informationsseite besteht daraus keine pauschale Pflicht, Cross-Origin-Isolation zu aktivieren. Für eine Anwendung, die geteilten Speicher benötigt, kann dieser Browserzustand dagegen eine konkrete Voraussetzung sein. Nicht unterstützende Clients und funktionierende Alternativen gehören dann zur Produktentscheidung. HTML: Cross-Origin-Policies

Der Web Security Check liest die Header der finalen Antwort nach Weiterleitungen. Aus passenden Werten kann er eine Konfiguration ableiten. Er führt jedoch keinen Browser aus und misst weder crossOriginIsolated noch die Beziehungen Ihrer Popups oder die Verträglichkeit aller nachgeladenen Ressourcen.

Drei Aufgaben, keine austauschbaren Header

COOP: die Fensterbeziehung bestimmen

same-origin trennt die Beziehung zu einem andersartigen Popup, wenn Origins und beteiligte Policies nicht passen. same-origin-allow-popups erlaubt bestimmte selbst geöffnete Popups mit unsafe-none, ist aber kein Ersatz für same-origin beim üblichen COOP/COEP-Weg zur Isolation. unsafe-none ist der Standardwert und fordert selbst keine zusätzliche Trennung; die Policy des anderen Dokuments kann trotzdem eine bewirken.

Der HTML-Standard kennt außerdem noopener-allow-popups. Das trennt die Beziehung zum Öffner, schafft jedoch keine umfassende Sicherheitsgrenze zwischen Anwendungen derselben Origin: gemeinsame Speicher und andere Zugriffswege bleiben zu berücksichtigen. Die seltenere Variante und ihre Browserunterstützung gehören in eine gezielte Architekturprüfung, nicht in ein pauschales Headerpaket. HTML § 7.1.3

COEP: Requestmodus und Antwort zusammen betrachten

Bei require-corp benötigen Cross-Origin-Ressourcen im no-cors-Modus eine passende CORP-Freigabe. Lädt das Element stattdessen im CORS-Modus, muss der CORS-Zugriff erfolgreich sein. Ein Access-Control-Allow-Origin auf dem Server allein ändert noch nicht den Modus eines gewöhnlichen <img>-Requests.

credentialless lässt Cross-Origin-no-cors-Ressourcen ohne ausdrückliche CORP-Freigabe zu, indem Credentials für diese Requests weggelassen werden. Eine ausdrücklich einschränkende CORP-Policy wird dadurch nicht unwirksam. CORS-Requests bleiben an CORS gebunden. Personalisierte Ressourcen können ohne ihre Credentials anders aussehen oder ausfallen; Frames haben zusätzliche Bedingungen.

Der Wert ist nicht überall verfügbar: Die am 27.09.2026 gelesenen Kompatibilitätsdaten führen credentialless für Chromium und Firefox Desktop, nicht für Safari und Firefox Android. Das ist dokumentierter Implementierungsstand, keine eigene Geräteabnahme. unsafe-none fordert keine zusätzliche COEP-Beschränkung. HTML § 7.1.4

CORP: die Ressource für die gewünschte Nutzung ausliefern

same-origin beschränkt die erfasste Nutzung auf dieselbe Origin. same-site erlaubt unter den Fetch-Regeln einen weiteren Domainzusammenhang, ist aber keine Gleichsetzung mit einem vertrauenswürdigen Unternehmen. Eine fremd verwaltete Unterdomain kann dazugehören. Der Algorithmus enthält zudem eine Transportbedingung: Eine über HTTPS gelieferte Ressource wird einem HTTP-Initiator nicht allein wegen gleicher Domainbeziehung freigegeben. cross-origin erlaubt die erfasste Nutzung durch andere Origins; das kann für ein öffentliches CDN gerade die richtige Einstellung sein.

CORP erteilt keine CORS-Leseberechtigung. Es verhindert auch nicht, dass ein anderer HTTP-Client die öffentlich erreichbare Datei abruft. Ein blockierter Bildaufruf beweist deshalb keine vollständige Hotlinking- oder Zugangssperre. Fetch § 3.7

Ein Bild unter require-corp: zwei zulässige Wege

Die lokale Chromium-Probe bestätigte diese Gegenfälle. Bei Frames genügt diese Bildtabelle nicht: Unter COEP müssen auch die eingebetteten Dokumente die entsprechenden Embedder-Policy-Bedingungen erfüllen. Ein CORP-Header auf einem iframe-Ziel allein ist deshalb keine universelle Reparatur.

Für den üblichen COOP/COEP-Weg zur Cross-Origin-Isolation lautet ein Ausgangspunkt:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Dazu gehören ein sicherer Kontext, ein unterstützender Browser und die übrigen Policybedingungen, insbesondere keine verweigernde cross-origin-isolated-Permissions-Policy. CORP ist kein obligatorischer dritter Dokumentheader. Prüfen Sie im betreffenden Dokument:

console.log({ secure: window.isSecureContext, isolated: window.crossOriginIsolated });

Der Wert beschreibt diesen Kontext. Er bestätigt weder jede eingebettete Seite noch die konkrete Betriebssystem-Prozessaufteilung oder eine getestete Spectre-Abwehr. Neuere alternative Mechanismen sind unter zusätzlichen Headern eingeordnet.

Einführung nach dem tatsächlichen Nutzerweg

1. Legen Sie fest, ob Fenstertrennung, Ressourcenbeschränkung oder Cross-Origin-Isolation benötigt wird. Erfassen Sie Drittbilder, Fonts, Skripte, Frames, Worker und Popups.
2. Ordnen Sie jede Antwort ihrem Betreiber zu. Eine CORP-Freigabe muss vom Ressourcenserver kommen; ein Header nur auf der eigenen Startseite repariert keine fremde Antwort.
3. Erproben Sie die beabsichtigten Regeln in einer isolierten Umgebung. COOP-/COEP-Report-Only kann Konflikthinweise liefern, wenn Reporting tatsächlich eingerichtet und unterstützt ist. Fehlende Reports belegen keine Verträglichkeit; siehe Reporting API.
4. Prüfen Sie positive und negative Fälle: gewollte Bilder und Frames, Anmeldung, Zahlung, Popup-Kommunikation sowie die benötigte API. Kontrollieren Sie Konsolenfehler, gesendete Requestmodi und den tatsächlichen Isolationszustand.
5. Rollen Sie begrenzt aus. Halten Sie die vorige Headerkonfiguration, passende Anwendungsversion und Cachebehandlung als Rückweg bereit. Nach einer Rücknahme müssen Dokumente neu geladen und Fensterbeziehungen neu aufgebaut werden.

Es gibt keine allgemein risikoarme Reihenfolge „erst COOP, dann CORP, dann COEP“. Schon COOP kann einen Login-Popupweg und CORP ein vorgesehenes Bild blockieren. Mehrfach ausgelieferte COEP-Werte wie require-corp, require-corp bilden keine Verstärkung: Das strukturierte Feld ist dann ungültig und fällt nach Standard auf den Ausgangswert zurück. Bereinigen Sie die zuständige Auslieferungsarchitektur.

Abgrenzung zu CORS, Berechtigungen und Compliance

CORS regelt, ob Browsercode eine bestimmte Cross-Origin-Antwort lesen darf. Die hier beschriebenen Mechanismen lösen andere Aufgaben. Keiner davon ersetzt Authentifizierung, serverseitige Autorisierung, CSP oder die Vertrauensprüfung eines zugelassenen Skripts. Für API-spezifische Fragen führt der API-Ratgeber weiter.

Aus einer solchen Konfiguration folgt keine allgemeine NIS2-/PCI-Pflichterfüllung. Ein zugelassenes kompromittiertes Skript kann weiterhin im Dokument handeln; die Header inventarisieren oder autorisieren keine Zahlungsskripte. Auch eine konkrete Prozessisolation wird vom Headercheck nicht gemessen. Compliance-Übersicht