COOP/COEP aktiv – Login kaputt? Cross-Origin Isolation sicher ausrollen
Cross-Origin Isolation kann leistungsfähige Browser-APIs ermöglichen, aber Popups und Drittanbieter-Ressourcen brechen. So prüfen Sie COOP, COEP, CORP/CORS und echte Nutzerflüsse vor dem Rollout.
COOP/COEP aktiv – Login kaputt? Cross-Origin Isolation sicher ausrollen
Das Team aktiviert zwei Header, damit eine WebAssembly-Anwendung SharedArrayBuffer nutzen kann und window.crossOriginIsolated endlich true liefert. Im technischen Test sieht alles richtig aus. Dann meldet sich der erste Nutzer: „Mit Google anmelden“ öffnet nur noch ein leeres Fenster. Kurz darauf funktioniert ein Zahlungsanbieter nicht mehr zuverlässig, und auf einer anderen Route fehlt ein Bild vom externen CDN.
Das Problem ist nicht Cross-Origin Isolation an sich. Das Problem ist, COOP und COEP wie dekorative Security-Header zu behandeln. Sie verändern, welche Browserkontexte miteinander verbunden bleiben und welche Cross-Origin-Ressourcen überhaupt geladen werden dürfen.
COOP und COEP kontrollieren unterschiedliche Grenzen
Cross-Origin-Opener-Policy (COOP) steuert, ob Top-Level-Dokumente, die etwa über Window.open() verbunden sind, in derselben Browsing Context Group bleiben. Mit same-origin können nicht passende Cross-Origin-Dokumente in eine andere Gruppe wechseln; Referenzen zwischen Opener und geöffnetem Fenster können dadurch getrennt werden.
Cross-Origin-Embedder-Policy (COEP) kontrolliert dagegen, welche Cross-Origin-Ressourcen ein Dokument laden oder einbetten darf. Mit require-corp brauchen Cross-Origin-Ressourcen, die im no-cors-Modus geladen werden, eine passende Freigabe über Cross-Origin Resource Policy (CORP). Ressourcen im CORS-Modus müssen weiterhin über CORS erlaubt werden.
Für echte Cross-Origin Isolation ist typischerweise COOP: same-origin zusammen mit COEP: require-corp oder credentialless nötig. Zusätzlich darf Permissions-Policy: cross-origin-isolated die Funktion nicht blockieren. Der Browser liefert mit window.crossOriginIsolated einen direkten Laufzeitindikator.
Warum Teams Isolation aktivieren
Bestimmte leistungsfähige Browser-Funktionen hängen von Cross-Origin Isolation ab. MDN nennt unter anderem SharedArrayBuffer, höhere Präzision bei Performance.now() und Performance.measureUserAgentSpecificMemory(). Das kann für komplexe Editoren, Multimedia, CAD, Emulatoren oder rechenintensive WebAssembly-Anwendungen relevant sein.
Die erste Frage sollte deshalb lauten: Welche konkrete Funktion oder Sicherheitsgrenze brauchen wir – und auf welchen Seiten? „Ein Scanner empfiehlt den Header“ ist keine Architekturbegründung.
Red Flag 1: Login oder Payment nutzt ein Cross-Origin-Popup
Viele Authentifizierungs- und Zahlungsflüsse öffnen ein fremdes Fenster und erwarten danach Kommunikation mit der ursprünglichen Seite. COOP: same-origin kann diese Beziehung trennen.
same-origin-allow-popups existiert für Integrationen, bei denen ein Dokument vertrauenswürdige Cross-Origin-Popups öffnen und eine Referenz behalten muss, etwa bei OAuth- oder Payment-Flows. Aber hier liegt ein wichtiger Zielkonflikt: Volle Cross-Origin Isolation verlangt COOP: same-origin; ein Wechsel zu same-origin-allow-popups ist nicht einfach „Isolation plus Popup-Kompatibilität“.
Das kann eine Architekturentscheidung erzwingen: Muss die ganze Website isoliert sein? Kann nur die WebAssembly-App isoliert werden? Kann Login auf einen Redirect-Flow oder FedCM wechseln? Kann Payment ohne dauerhafte Opener-Beziehung abgeschlossen werden?
Google dokumentiert aktuell ausdrücklich, dass COOP den „Sign in with Google“-Popup-Flow beeinflussen kann. Bei deaktiviertem FedCM kann eine ungeeignete Konfiguration die Kommunikation zwischen Fenstern unterbrechen und zu einem leeren Popup oder ähnlichen Fehlern führen. Login, Checkout und Identitätsprüfung gehören deshalb vor einen globalen Rollout in die Testmatrix.
Red Flag 2: COEP blockiert bisher unauffällige Drittanbieter-Ressourcen
Mit COEP: require-corp werden Cross-Origin-Ressourcen bewusster Teil Ihrer Vertrauensgrenze. Betroffen sein können Bilder, Medien, CDN-Skripte, Web Fonts, Worker-Abhängigkeiten, Widgets, Support-Komponenten oder Ressourcen aus Storage-Domains.
Bei no-cors braucht die Ressource eine passende CORP-Antwort. Alternativ kann sie im CORS-Modus geladen werden, wenn der Anbieter CORS korrekt erlaubt. Der operative Haken: Den Antwort-Header eines Drittanbieters kontrollieren Sie häufig nicht.
Vor dem Rollout sollten Sie deshalb inventarisieren, welche fremden Origins die realen Produktionsseiten laden, welchen Request-Modus sie verwenden und ob CORP oder CORS tatsächlich passt.
credentialless ist kein kostenloser Kompatibilitätsmodus
COEP unterstützt auch credentialless. Damit können bestimmte Cross-Origin-Ressourcen im no-cors-Modus ohne explizite CORP-Freigabe geladen werden – allerdings ohne Credentials. Cookies werden beim Request weggelassen.
Das kann für öffentliche statische Ressourcen sinnvoll sein. Es ist aber kein „alles funktioniert wieder“-Schalter. Wenn eine Ressource Inhalte, Personalisierung oder Berechtigungen über Cookies bestimmt, verändert credentialless ihr Verhalten. Fragen Sie deshalb: Braucht diese Ressource Credentials, und ist das Ergebnis ohne sie fachlich korrekt?
Red Flag 3: Die Header werden global am CDN gesetzt
Eine Regel wie „diese Security-Header auf alle HTML-Antworten“ ist bequem, bei COOP/COEP aber möglicherweise zu breit. Wenn nur /editor SharedArrayBuffer benötigt, während Marketingseite, Login, Checkout und Buchungswidget keine Isolation brauchen, steigt die Kompatibilitätsfläche ohne klaren Nutzen.
Prüfen Sie die kleinste sinnvolle Grenze: eigene App-Subdomain, separater Einstiegspunkt oder nur die Dokumente, die Isolation tatsächlich benötigen. Eine kleine Grenze lässt sich leichter testen und warten als eine globale Policy mit immer mehr Ausnahmen.
Red Flag 4: Es wurde nur die Startseite getestet
Ein belastbarer Rollout testet genau die Pfade, an denen Origins aufeinandertreffen: Login, Social Login, SSO, MFA, Checkout, Payment-Popup, Buchung, Chat, Karten, Video, Identity-Verifikation, Web Worker, WebAssembly, Uploads, CDN-Assets, Fonts und dynamische Imports.
Eine Policy, die auf / funktioniert, sagt fast nichts über einen Checkout mit drei externen Diensten aus.
Red Flag 5: Niemand prüft crossOriginIsolated zur Laufzeit
Wenn eine Funktion von Isolation abhängt, sollte die Anwendung nicht nur darauf vertrauen, dass „der Proxy die Header setzt“. Prüfen Sie window.crossOriginIsolated und definieren Sie einen verständlichen Fallback.
Zusätzlich gehören die tatsächlich ausgelieferten Header, Permissions-Policy, blockierte Netzwerkressourcen, Worker-Kontexte und relevante Browser in automatisierte oder reproduzierbare Tests. Eine CDN-Änderung sollte nicht unbemerkt aus einer produktiven Funktion eine kryptische Exception machen.
Ein praktischer Rollout-Plan
Erstellen Sie vor der Durchsetzung eine kleine Karte der Cross-Origin-Abhängigkeiten. Für jeden kritischen Flow sollten Sie wissen: welches Dokument isoliert werden soll, warum es Isolation braucht, welche Popups es öffnet, welche Drittanbieter-Origins geladen werden, welche Requests no-cors oder CORS verwenden, welche Ressourcen CORP liefern und welche Cookies oder andere Credentials benötigen.
COEP-Verstöße können über die Reporting API sichtbar gemacht werden; Cross-Origin-Embedder-Policy-Report-Only kann beim schrittweisen Rollout helfen. Reporting bleibt aber nur ein Signal. Kombinieren Sie es mit echten Browser-Smoke-Tests, synthetischen Login- und Checkout-Tests, JavaScript-/Netzwerkmonitoring und einer klaren Rollback-Strategie für Header-Änderungen.
Was Website-Pflichtencheck dabei prüfen würde
Ein Cross-Origin-Isolation-Audit würde unter anderem prüfen:
- COOP- und COEP-Header auf repräsentativen Routen,
window.crossOriginIsolatedund Worker-Kontexte,SharedArrayBufferund andere isolationsabhängige APIs,- OAuth-, SSO-, Payment- und Popup-Flows,
window.openerund Cross-Window-Kommunikation,- Drittanbieter-Ressourcen und Request-Modi,
- CORP- und CORS-Antworten,
- Auswirkungen von
credentialless, - CDN-, Reverse-Proxy- und Framework-Konfiguration,
- Reporting, Browsertests, Fallbacks und Rollback-Fähigkeit.
Das Ziel ist nicht der strengste Header um jeden Preis. Das Ziel ist eine belastbare Aussage: Diese Oberfläche braucht Cross-Origin Isolation, diese Ressourcen und Nutzerflüsse sind damit kompatibel, und wir merken schnell, wenn eine Abhängigkeit sich ändert.
Wenn COOP und COEP heute nur deshalb global gesetzt sind, weil sie in einem kopierten Security-Header-Snippet standen, ist das ein guter Anlass für einen technischen Check. Ein Sicherheitsmechanismus sollte die Angriffsfläche verkleinern – nicht den Login verschwinden lassen.