COOP, COEP, CORP: Cross-Origin-Header richtig setzen

Drei Header, drei Aufgaben, drei Ebenen

Die Namensähnlichkeit ist der eigentliche Grund für die meisten Fehlkonfigurationen. Cross-Origin-Opener-Policy wirkt auf die Fenstergruppe: Sie entscheidet, ob ein Dokument mit dem Fenster verbunden bleibt, das es geöffnet hat. Cross-Origin-Embedder-Policy wirkt auf das Dokument und alles, was es nachlädt: Sie verlangt für jede Unterressource eine ausdrückliche Freigabe. Cross-Origin-Resource-Policy wirkt auf die einzelne Antwort und wird von der ausliefernden Seite gesetzt: Sie sagt, wer diese Ressource einbetten darf. Der erste Header schützt das eigene Fenster, der zweite die eigene Ladeliste, der dritte das eigene Material vor fremder Einbindung. Eine Einordnung aller gebräuchlichen Sicherheitsköpfe steht im Beitrag zu den HTTP-Security-Headern.

Dass die drei zusammen genannt werden, hat einen technischen Grund: Zwei von ihnen greifen ineinander. Ein Dokument gilt erst dann als cross-origin-isoliert, wenn es COOP auf same-origin setzt und zusätzlich COEP auf require-corp oder credentialless (MDN Web Docs). Erst dieser Zustand gibt Schnittstellen frei, die der Browser sonst gesperrt hält. CORP ist dabei die Gegenseite: Ohne Freigabe der ausliefernden Ressource kommt ein Dokument mit require-corp an fremdes Material nicht heran. Wer nur einen der drei Header setzt, verändert damit bereits das Verhalten - die volle Schutzwirkung entsteht aber erst im Zusammenspiel, und genau dieses Zusammenspiel ist die Stelle, an der Konfigurationen auseinanderlaufen.

• Cross-Origin-Opener-Policy (COOP): gültige Werte sind unsafe-none, same-origin-allow-popups, same-origin und das jüngere noopener-allow-popups.
• Cross-Origin-Embedder-Policy (COEP): gültige Werte sind unsafe-none, require-corp und credentialless.
• Cross-Origin-Resource-Policy (CORP): gültige Werte sind same-origin, same-site und cross-origin.
• COOP und COEP setzt das Dokument, CORP dagegen jede einzelne Antwort - Bild, Schriftdatei, Skript, eingebetteter Rahmen.
• Ungültige Werte fallen still zurück: Der Browser meldet keinen Fehler, er nimmt die Voreinstellung und lädt weiter.
• Gelesen wird der Antwortkopf, nicht das HTML: Ein meta-Element ersetzt keinen der drei Header.

Wie eng die drei beieinanderliegen, zeigt die Fehlerverteilung im offenen Web: 5,6 Prozent aller beobachteten COEP-Header tragen einen Wert, den der Browser an dieser Stelle nicht kennt (Web Almanac 2025). Über 4 Prozent entfallen dabei auf same-origin - ein gültiger Wert, aber für CORP oder COOP, nicht für COEP (Web Almanac 2025). Der Browser verwirft die Angabe und arbeitet weiter, als stünde sie nicht da. Im Seitenbild bleibt das unsichtbar; sichtbar wird es erst, wenn jemand den Antwortkopf ausliest und den Wert gegen die erlaubte Liste hält.

COOP: der Schnitt durch die Fenstergruppe

Ein Fenster, das ein anderes öffnet, behält eine Verbindung zu ihm: window.opener. Über diese Verbindung lassen sich Eigenschaften abfragen und in bestimmten Konstellationen Seiteneffekte auslösen. COOP schneidet diese Verbindung durch. Mit same-origin bleibt nur bestehen, was denselben Origin hat; alles andere wird in eine eigene Fenstergruppe verschoben und sieht statt des Öffners den Wert null. same-origin-allow-popups ist die mildere Stufe: Das Dokument trennt sich von seinem Öffner, behält aber die Verbindung zu Fenstern, die es selbst öffnet. unsafe-none entspricht der Voreinstellung und ändert am bisherigen Verhalten nichts.

Wer COOP setzt, wählt inzwischen mehrheitlich die strengste Stufe: Der Anteil von same-origin an allen COOP-Headern stieg binnen eines Jahres von 47,5 auf 61,6 Prozent (Web Almanac 2025). Der jüngere Wert noopener-allow-popups, der die Fenstergruppe trennt, ohne die geöffneten Pop-ups zu verlieren, liegt dagegen bei 0,03 Prozent (Web Almanac 2025) - er ist in der Fläche noch nicht angekommen. Für Betreiber heißt das zweierlei: Die strenge Stufe ist unter den Anwendern zum Normalfall geworden, und die schonenden Zwischenstufen sind so selten verbreitet, dass es zu ihnen wenig Erfahrungswerte gibt.

COEP: die Ladeschranke für Unterressourcen

COEP dreht die Beweislast um. Ohne den Header lädt ein Dokument fremde Bilder, Schriften und Skripte ohne Rückfrage; mit require-corp muss jede Unterressource eine Freigabe mitbringen - entweder einen CORP-Kopf oder eine erfolgreiche CORS-Antwort. Fehlt beides, blockiert der Browser die Ressource. credentialless ist der schonendere Weg: Die Ressource wird geladen, aber ohne Anmeldedaten, also ohne Cookies und ohne clientseitige Zertifikate. Für öffentliche Bilder und Schriften genügt das; alles, was eine Sitzung braucht, bekommt eine anonyme Antwort. Welche Rolle die Cookie-Attribute dabei spielen, ordnet der Beitrag zu sicheren Sitzungs-Cookies ein.

Die Verteilung der gesetzten Werte zeigt, wie zurückhaltend der Header eingesetzt wird. Über 86 Prozent aller COEP-Header auf mobilen Abrufen tragen unsafe-none und schalten die Wirkung damit wieder ab (Web Almanac 2025). require-corp kommt auf 4,92 Prozent, credentialless auf 1,89 Prozent (Web Almanac 2025). Der Anteil von unsafe-none ist gegenüber dem Vorjahr um knapp zwei Prozentpunkte gefallen - eine Bewegung, aber eine langsame. Wer den Header setzt, setzt ihn also überwiegend so, dass er nichts bewirkt: als Platzhalter, als Rest einer Vorlage oder als vorbereiteter Schalter, der bislang nicht umgelegt wurde.

CORP: die Antwort der Gegenseite

CORP ist der einzige der drei Header, den nicht das einbettende Dokument setzt, sondern die ausgelieferte Ressource selbst. same-origin gibt sie nur für den eigenen Origin frei, same-site für die eigene Site einschließlich der Unterdomänen, cross-origin für jedes Dokument. Der Header ist damit zugleich Schutz und Freigabe: Er verhindert, dass fremde Seiten eigene Bilder oder Skripte einbetten, und er ist die Voraussetzung dafür, dass eigene Ressourcen in einem Dokument mit require-corp überhaupt ankommen. Wer einen eigenen Auslieferungspfad für Bilder und Schriften betreibt, entscheidet an dieser Stelle über beide Richtungen gleichzeitig.

In der Praxis wird CORP überwiegend als Freigabe benutzt: 80,5 Prozent der beobachteten CORP-Header auf mobilen Abrufen tragen cross-origin (Web Almanac 2025). Dieser Anteil ist gegenüber dem Vorjahr um mehr als zehn Prozentpunkte gefallen, während same-origin auf 15,63 Prozent gestiegen ist (Web Almanac 2025). Die Bewegung geht also in Richtung Abriegelung: Mehr Anbieter beschränken ihre Ressourcen auf den eigenen Origin. Für Einbindende heißt das, dass eine Einbettung, die gestern noch ohne Weiteres funktionierte, heute eine Freigabe verlangen kann, die es an dieser Stelle nicht mehr gibt - ein Zustand, der sich nur durch Nachmessen bemerkbar macht.

• CORP ersetzt CORS nicht: Es regelt die Einbettung, nicht den Lesezugriff per Skript. Die Abgrenzung und die häufigsten Fehlkonfigurationen stehen im Beitrag zu CORS-Konfigurationsfehlern.
• CORP schützt Inhalte nicht vor dem direkten Abruf: Der Aufruf der Adresse im Browser bleibt möglich.
• CORP wirkt je Antwort: Ein Pfad kann freigegeben sein, der daneben nicht - der Zwischenspeicher davor merkt sich beide Zustände.
• CORP ohne COEP auf der Gegenseite bleibt folgenlos: Ein Dokument ohne require-corp fragt die Freigabe nicht ab.
• CORP im HTML wirkt nicht: Der Wert wird ausschließlich aus dem Antwortkopf gelesen, nicht aus einem Element im Kopfbereich.

Für die eigene Auslieferung ergibt sich daraus eine einfache Reihenfolge. Zuerst wird getrennt, was öffentlich eingebettet werden soll und was nicht: Logos, Schriften und offene Bilddateien bekommen cross-origin, alles mit Bezug zu einer Sitzung bekommt same-origin. Danach wird geprüft, ob eine vorgelagerte Auslieferungsschicht die Kopfzeile mitführt - eine Datei ohne CORP-Kopf verhält sich unter require-corp wie eine gesperrte Datei, unabhängig davon, was am Ursprungsserver konfiguriert ist. Warum Zwischenspeicher nach einer Auslieferung veraltete Antworten weitergeben, beschreibt der Beitrag zu Cache-Fallen nach dem Deploy.

Was die Cross-Origin-Isolation zurückgibt

Der Aufwand hat einen Zweck. Ein Dokument, das COOP auf same-origin und COEP auf require-corp oder credentialless setzt, erreicht den Zustand crossOriginIsolated (MDN Web Docs). In diesem Zustand gibt der Browser Schnittstellen frei, die er sonst gesperrt hält: gemeinsam genutzten Speicher zwischen Haupt- und Hintergrundfaden, die Messung des eigenen Speicherverbrauchs und die volle Auflösung der Zeitmessung. Für rechenintensive Anwendungen im Browser - Bildbearbeitung, Kartenberechnung, Simulation, Datenanalyse - ist das der Unterschied zwischen brauchbar und unbrauchbar. Für eine gewöhnliche Inhaltsseite ist es dagegen ein Zustand ohne erkennbaren Gegenwert.

Am deutlichsten wird der Unterschied bei der Zeitmessung. In einem isolierten Kontext liefert performance.now() eine Auflösung von 5 Mikrosekunden (MDN Web Docs), außerhalb sind es 100 Mikrosekunden (MDN Web Docs). Der Faktor 20 ist keine Sparmaßnahme, sondern eine Abwehr: Feine Zeitmessung ist der Hebel für Seitenkanalangriffe der Spectre-Familie. Wer Laufzeitunterschiede genau genug messen kann, liest indirekt Speicherinhalte fremder Herkunft mit, die im selben Prozess liegen. Der Browser vergröbert deshalb die Uhr für alle Dokumente, die ihre Umgebung nicht abgeschottet haben, und gibt sie erst zurück, wenn die Abschottung nachgewiesen ist.

Wie selten dieser Zustand tatsächlich erreicht wird, zeigt die Messung an echten Seitenaufrufen. Der Chrome-Zähler für Dokumente mit COOP- und COEP-Isolation steht bei einem Anteil von 0,00136697 an allen Seitenaufrufen, also rund 0,14 Prozent (Chrome Platform Status 2026). Der neuere Mechanismus Document Isolation Policy, der die Isolation ohne den Schnitt durch die Fenstergruppe erreichen soll, liegt mit 0,00656973 bereits darüber (Chrome Platform Status 2026). Cross-Origin-Isolation ist damit kein Grundzustand des Webs, sondern eine gezielte Entscheidung für einzelne Anwendungen - und die Zahlen deuten darauf hin, dass der Weg dorthin gerade umgebaut wird.

Die Werte, die verwechselt werden

Jeder der drei Header kennt seine eigene Werteliste, und die Listen überschneiden sich teilweise. same-origin ist für COOP und CORP gültig, für COEP nicht. cross-origin gehört zu CORP, nicht zu den anderen beiden. require-corp und credentialless gehören zu COEP. unsafe-none gibt es bei COOP und COEP, bei CORP nicht. Wer einen Wert aus der falschen Liste einträgt, bekommt keine Warnung: Der Browser verwirft die Kopfzeile und arbeitet mit der Voreinstellung weiter. Genau deshalb ist der tatsächlich ausgelieferte Wert eine Messgröße und keine Annahme - er gehört ausgelesen und gegen die erlaubte Liste geprüft.

Der Weg über die Beobachtungsfassung

Beide Dokumentheader haben eine Beobachtungsfassung: Cross-Origin-Opener-Policy-Report-Only und Cross-Origin-Embedder-Policy-Report-Only. Sie ändern das Verhalten des Browsers nicht, sondern melden, was unter der scharfen Fassung geschehen wäre. Zusammen mit einem Reporting-Endpoints-Kopf, der ein Berichtsziel benennt, entsteht daraus eine belastbare Liste der Stellen, die brechen würden - bevor sie brechen. Für COEP sind das die Ressourcen ohne Freigabe, für COOP die Fensterbeziehungen, die getrennt würden. Beide Fassungen lassen sich parallel zur scharfen Fassung eines strengeren Werts fahren und liefern damit eine Vorschau auf die nächste Stufe.

Zwei Dinge entscheiden über den Wert dieser Vorstufe. Erstens die Laufzeit: Eine Woche deckt den Wochenrhythmus ab, ein Monat auch Abrechnungsläufe, Kampagnenstarts und saisonale Einbindungen. Zweitens die Abdeckung: Berichte entstehen nur auf Seiten, die tatsächlich aufgerufen werden. Ein Bereich ohne Verkehr liefert keine Berichte und erscheint dadurch als unauffällig, obwohl er ungeprüft geblieben ist. Wer die Vorstufe ernst nimmt, gleicht die Berichtsquellen deshalb gegen ein Verzeichnis der eigenen Adressen ab, statt eine leere Liste als Ergebnis zu verbuchen - ein leeres Messergebnis und ein ausgefallenes Messverfahren sehen von außen gleich aus.

Der Anteil dieses Wertes liegt auf mobilen Abrufen weiterhin über 86 Prozent, ist gegenüber dem Vorjahr aber um fast 2 Prozent gefallen, was darauf hindeuten kann, dass Entwickler ihren Umgang mit dem Header zu ändern beginnen.

— Web Almanac 2025, Kapitel Security, sinngemäß übersetzt

Was beim Einbetten fremder Inhalte bricht

Der Schritt auf require-corp ist kein Eintrag in einer Konfiguration, sondern ein Eingriff in die Ladeliste. Betroffen ist alles, was aus fremder Herkunft kommt: Kartenausschnitte, Videoeinbindungen, Schriftdateien, Zahlungsfenster, Zählpixel, Profilbilder aus einem fremden Speicher. Jede dieser Ressourcen braucht danach eine CORP-Freigabe oder eine gültige CORS-Antwort. Wer die Freigabe nicht selbst setzen kann, weil die Ressource von fremder Seite ausgeliefert wird, hat drei Möglichkeiten: credentialless statt require-corp, eine eigene Zwischenauslieferung mit eigenem Antwortkopf oder den Verzicht auf die Einbindung. Alle drei sind Entscheidungen mit Folgen, keine Schalter.

Der Umfang dieses Eingriffs lässt sich beziffern. Mindestens 90 Prozent aller Seiten binden mindestens einen Drittanbieter ein (Web Almanac 2025), und der Median liegt bei 83 Anfragen an fremde Server auf dem Desktop und 79 auf mobilen Geräten (Web Almanac 2025). Allein an eingebetteten Rahmen wurden im mobilen Abruf 33,3 Millionen gezählt (Web Almanac 2025). Jede einzelne dieser Anfragen ist unter require-corp ein möglicher Blockadefall. Welche Risiken fremde Skripte darüber hinaus tragen, beschreibt der Beitrag zu Drittanbieter-Skripten; die Absicherung einzelner eingebundener Dateien behandelt der Beitrag zu Subresource Integrity.

# Stufe 1: beobachten - Berichte sammeln, nichts blockieren
add_header Reporting-Endpoints 'iso="https://example.test/berichte/iso"' always;
add_header Cross-Origin-Opener-Policy-Report-Only 'same-origin; report-to="iso"' always;
add_header Cross-Origin-Embedder-Policy-Report-Only 'require-corp; report-to="iso"' always;

# Stufe 2: scharf schalten, erst wenn die Berichte leer bleiben
# add_header Cross-Origin-Opener-Policy 'same-origin' always;
# add_header Cross-Origin-Embedder-Policy 'require-corp' always;

# Eigene Bilder und Schriften an fremde Dokumente ausliefern
location /assets/ {
    add_header Cross-Origin-Resource-Policy 'cross-origin' always;
}

# Alles mit Sitzungsbezug bleibt beim eigenen Origin
location /konto/ {
    add_header Cross-Origin-Resource-Policy 'same-origin' always;
}

Wie verbreitet die drei Header wirklich sind

Das Wachstum ist stetig, aber es beginnt auf einer sehr kleinen Basis. COOP wurde 2022 auf 0,23 Prozent der Anfragen gefunden, 2023 auf 0,68 Prozent und 2024 auf 1,07 Prozent (Web Almanac 2024) - jedes Jahr rund eine Verdopplung. 2025 haben CORP und COOP erstmals die Marke von zwei Prozent überschritten (Web Almanac 2025), COEP liegt bei knapp 0,75 Prozent (Web Almanac 2025). Die Erhebung, auf der diese Anteile beruhen, umfasst 16.213.084 Websites aus dem Crawl vom Juli 2025 (Web Almanac 2025) - die Zahlen sind also keine Stichprobe aus einer Nische.

• Transportverschlüsselung ist praktisch abgeschlossen: über 98,8 Prozent aller Anfragen auf mobilen Verbindungen laufen über HTTPS (Web Almanac 2025).
• Stärkster Zuwachs unter den Sicherheitsköpfen: Strict-Transport-Security mit +4,02 Prozentpunkten gegenüber dem Vorjahr (Web Almanac 2025).
• Das ältere Werkzeug wächst schneller: das sandbox-Attribut an eingebetteten Rahmen stieg von 20,0 auf 22,7 Prozent (Web Almanac 2025).
• Neuere Mechanismen bleiben klein: die Document Policy erreicht 0,10 Prozent der abgerufenen Seiten (Web Almanac 2025).
• Innerhalb der Anwender geht es zur Strenge: der COOP-Wert same-origin stieg von 47,5 auf 61,6 Prozent der COOP-Header (Web Almanac 2025).

Aus diesen Zahlen lassen sich zwei Schlüsse ziehen. Erstens: Die Cross-Origin-Header sind kein Grundschutz, den man nebenbei mitnimmt, sondern eine Entscheidung mit Folgen für jede Einbindung fremder Inhalte - deshalb liegen sie um Größenordnungen unter den Werten für Transportverschlüsselung und die etablierten Sicherheitsköpfe. Zweitens: Innerhalb der Gruppe, die sie setzt, geht die Bewegung klar in Richtung der strengeren Werte. Wer heute plant, plant deshalb sinnvollerweise für die strenge Stufe und für den Weg dorthin, nicht für den Zwischenzustand. Welche Bauteile im eigenen Bestand ohnehin ausgetauscht gehören, zeigt der Beitrag zu Komponenten ohne Wartungsunterstützung.

Die Header im Betrieb beobachten

Ein Antwortkopf ist ein flüchtiger Zustand. Er entsteht in der Anwendung, im Webserver, in einem vorgelagerten Zwischenspeicher oder in einer Auslieferungsschicht, und jede dieser Stellen kann ihn ergänzen, überschreiben oder entfernen. Eine Prüfung zum Zeitpunkt der Einrichtung sagt deshalb wenig über den Zustand drei Monate später. Beobachtet gehören vier Dinge: ob der Header vorhanden ist, welchen genauen Wert er trägt, ob er auf allen Adresstypen gleich gesetzt ist - HTML, Bilddatei, Schriftdatei, Schnittstellenantwort - und ob die eingebetteten Ressourcen ihre Freigabe weiterhin mitliefern.

Praktisch heißt das: eine Liste der zu prüfenden Adressen, ein fester Takt, ein hinterlegter Sollwert je Header und eine Meldung bei Abweichung. Der Security-Scan liest die Antwortköpfe aus und vergleicht sie mit dem hinterlegten Zustand; für den schnellen Einzelblick auf eine Adresse genügt der Security-Score. Für Abläufe, die ein zweites Fenster öffnen, ergänzt Browser-Monitoring die Kopfprüfung um den tatsächlichen Ablauf. Wie ein Prüfendpunkt aufgebaut sein muss, damit er den Zustand hinter der Oberfläche meldet, beschreibt der Beitrag zum Health-Check-Endpunkt; dass ein Abruf im Browser etwas anderes ist als ein Abruf aus einer Anwendung, zeigt der Beitrag zur unvollständigen Zertifikatskette.