Cross-Origin-Isolation — COOP, COEP, CORP

Würdigung — was Cross-Origin-Isolation ist und woher sie kommt#

Der Anlass für diese Header-Familie ist konkret und datiert: die Spectre-Lücke, 2018 öffentlich gemacht. Sie zeigte, dass ein bösartiges Skript über Seitenkanäle (Timing-Messungen) Speicher auslesen kann, der eigentlich einer anderen Herkunft (Origin) gehört. Die Antwort der Browser-Hersteller war, mächtige Funktionen wie SharedArrayBuffer und hochauflösende Timer nur noch dann freizugeben, wenn eine Seite nachweislich von fremden Inhalten isoliert ist — eben „cross-origin isolated".

Diese Isolation ist nicht der Standard. Eine normale Website lädt selbstverständlich Bilder, Schriften, Skripte und Einbettungen von verschiedenen Herkünften. Cross-Origin-Isolation kehrt diese Offenheit um: Standardmäßig wird alles Fremde misstrauisch behandelt, und nur explizit freigegebene Ressourcen dürfen in den isolierten Kontext.

Für eine Steuerkanzlei-Website ist das zunächst abstrakt. Der praktische Wert liegt in zwei Punkten: Erstens schließt die Isolation eine ganze Klasse von Cross-Origin-Informationslecks — relevant für eine Seite, die unter dem Vertrauensanspruch des § 203 StGB steht. Zweitens ist sie ein sichtbares Zeichen von Tiefe. Wer COOP und COEP korrekt setzt, hat sich mit der Materie befasst und nicht nur ein Plugin installiert.

COOP — die Fenster-Isolation#

Cross-Origin-Opener-Policy (COOP) regelt das Verhältnis Ihrer Seite zu Fenstern, die sie öffnet oder von denen sie geöffnet wurde. Ohne COOP behält ein per window.open() geöffnetes oder ein verweisendes Fenster eine Referenz auf Ihre Seite — über das window.opener-Objekt. Das ist die Grundlage für „Tabnabbing"-Angriffe und für Cross-Origin-Seitenkanäle.

Mit Cross-Origin-Opener-Policy: same-origin — der Wert, den wir auf fahoch2.de setzen — wird diese Verbindung gekappt: Ihre Seite landet in einer eigenen Browsing-Context-Gruppe, fremde Fenster verlieren die Referenz. Das ist der erste der beiden Bausteine, die zusammen die Isolation ergeben.

COEP — kontrollieren, was eingebettet werden darf#

Cross-Origin-Embedder-Policy (COEP) ist der zweite Baustein. Sie verlangt, dass jede cross-origin geladene Ressource (Bild, Schrift, Skript) der Einbettung ausdrücklich zustimmt. Hier gibt es zwei Werte, und die Wahl ist eine echte Entscheidung:

• require-corp ist die strenge Variante: Jede Fremd-Ressource muss explizit per CORP-Header oder CORS zustimmen. Maximal sicher — aber wenn auch nur ein eingebundenes Fremd-Bild den passenden Header nicht mitschickt, bricht die Einbettung.
• credentialless ist die pragmatische Variante: Cross-Origin-Ressourcen werden ohne Anmelde-Daten (Cookies, Auth-Header) geladen. Das stellt die Isolation her, ohne dass jede Fremd-Quelle aktiv mitspielen muss.

Auf fahoch2.de setzen wir Cross-Origin-Embedder-Policy: credentialless. Der Grund ist Ehrlichkeit gegenüber der Praxis: Eine reale Website bindet gelegentlich Ressourcen ein, deren Header wir nicht kontrollieren. credentialless erreicht die Isolation, ohne dass eine vergessene Fremd-Ressource die Seite sichtbar beschädigt. Für ein Mandanten-Portal mit höchsten Anforderungen wäre require-corp plus sauber gesetzte CORP-Header die strengere Wahl.

Wenn COOP (same-origin) und COEP (credentialless oder require-corp) zusammenspielen, meldet der Browser self.crossOriginIsolated === true. Das ist der maschinell prüfbare Beleg, dass die Isolation greift.

CORP — die Gegenrichtung#

Während COEP steuert, was Ihre Seite einbetten darf, regelt Cross-Origin-Resource-Policy (CORP) die Gegenrichtung: Wer darf Ihre Ressourcen einbetten? Mit Cross-Origin-Resource-Policy: same-origin an einer Datei sagen Sie dem Browser, dass dieses Bild, diese Schrift, dieses Skript nur von der eigenen Domain geladen werden darf — nicht von einer fremden Seite, die Ihre Inhalte heißlinkt oder in einen Seitenkanal-Angriff einbaut.

Für eine Kanzlei-Seite, die ihre Assets selbst hostet (Schriften via next/font, eigene Bilder), ist CORP eine leise, kostenlose Härtung: Die eigenen Ressourcen werden gegen Fremd-Einbettung gesperrt. Es ist die Ressourcen-Ebene dessen, was X-Frame-Options und frame-ancestors auf der Dokument-Ebene tun — und Letzteres ist auch der Grund, warum sich Portale wie DATEV nicht per Iframe einbetten lassen, wie im Artikel zur DATEV-Portal-Integration beschrieben.

Braucht eine Kanzlei-Marketing-Seite das wirklich?#

Die ehrliche Antwort: nicht zwingend. SharedArrayBuffer und hochauflösende Timer braucht eine Steuerkanzlei-Website nicht — das sind Funktionen für Bildbearbeitung im Browser, WebAssembly-Schwergewichte, Spiele. Der Nutzen liegt woanders:

• Defense-in-Depth. COOP kappt window.opener-Lecks und Tabnabbing — das ist auch ohne den Isolations-Bonus ein realer Schutz.
• Konsistenz im Audit. Eine Seite, die die Cross-Origin-Familie sauber setzt, hebt sich von der großen Mehrheit ab, die bei den Standard-Headern stehenbleibt.
• Vorbereitung. Wenn später eine interaktive Funktion dazukommt, ist die Isolation bereits da.

Unsere Haltung auf fahoch2.de: Wir setzen COOP same-origin und COEP credentialless, weil die Kosten null sind und der Gewinn real — auch wenn die Seite keine isolations-pflichtige Funktion nutzt. Für eine vollständige Bestandsaufnahme aller Header-Ebenen inklusive Aufwand-Schätzung empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Cross-Origin-Isolation ist die fortgeschrittene Ebene über den Standard-Schutz-Headern. COOP isoliert das Fenster gegen window.opener-Lecks, COEP kontrolliert, welche Fremd-Ressourcen geladen werden dürfen (mit der pragmatischen Variante credentialless als Mittelweg), CORP sperrt die eigenen Ressourcen gegen Fremd-Einbettung. Zusammen ergeben COOP und COEP den Zustand crossOriginIsolated. Eine Marketing-Seite braucht die isolations-pflichtigen Browser-Funktionen nicht — aber die Header schließen reale Lecks zu Nullkosten und zeigen Tiefe. Wer die eigene Seite einordnen will, beginnt mit dem kostenfreien Header-Check und entscheidet danach, wie weit die Absicherung gehen soll.

Quellen#

• MDN — Cross-Origin-Opener-Policy — abgerufen 2026-05-29
• MDN — Cross-Origin-Embedder-Policy — abgerufen 2026-05-29
• MDN — Cross-Origin-Resource-Policy — abgerufen 2026-05-29
• web.dev — Why you need cross-origin isolation — abgerufen 2026-05-29
• OWASP Secure Headers Project — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Browser-Verhalten und Header-Spezifikationen entwickeln sich; maßgeblich ist die jeweils aktuelle MDN-/Spezifikations-Dokumentation.