COEP

Was ist COEP?

COEP (Cross-Origin Embedder Policy) ist ein HTTP-Response-Header, der eine Webseite in einen Zustand der Cross-Origin Isolation versetzt. In diesem Zustand sind bestimmte leistungsstarke Browser-APIs wieder verfügbar, die nach dem Spectre-Exploit 2018 browserübergreifend deaktiviert wurden — insbesondere SharedArrayBuffer und hochauflösende performance.now()-Timer.

Der Trade-off: Eine Seite mit COEP kann keine Cross-Origin-Ressourcen mehr laden, die nicht explizit über CORS freigegeben oder mit dem CORP-Header cross-origin versehen sind. Das macht COEP für komplexe Webseiten mit vielen Drittanbieter-Ressourcen zu einer signifikanten Umstellungsarbeit.

Wie funktioniert COEP?

COEP hat drei Werte:

• unsafe-none (Standard wenn nicht gesetzt): Keine Einschränkungen. Cross-Origin-Ressourcen dürfen frei geladen werden. SharedArrayBuffer ist nicht verfügbar.
• require-corp: Alle Cross-Origin-Ressourcen müssen entweder Cross-Origin-Resource-Policy: cross-origin setzen oder via CORS freigegeben sein. SharedArrayBuffer wird verfügbar.
• credentialless: Etwas weniger restriktiv als require-corp — Cross-Origin-Ressourcen ohne Credentials (Cookies) werden ohne CORP-Prüfung geladen. Neuerer Ansatz für einfachere Adoption.

Für volle Cross-Origin Isolation sind zwei Header zusammen erforderlich:

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

Der Browser stellt dann self.crossOriginIsolated === true bereit, was Zugriff auf SharedArrayBuffer ermöglicht.

COEP in der Praxis

COEP ist primär relevant für Anwendungen, die:

• WebAssembly mit Multithreading nutzen (WASM Threads benötigen SharedArrayBuffer)
• Web Audio API mit präzisen Timern
• Offscreen Canvas für parallele Rendering-Operationen

Für typische WordPress-Seiten ist COEP selten nötig. Relevant wird es bei WordPress-basierten Web-Apps mit Audio-/Video-Processing oder WASM-Modulen.

Die praktische Herausforderung: Jede externe Ressource (Google Fonts, YouTube-Embeds, Tracking-Pixel, CDN-Assets) muss CORP-kompatibel sein. Für viele Produktionsseiten ist das schwer umsetzbar, weshalb credentialless als pragmatischer Mittelweg entwickelt wurde.

Was passiert wenn COEP aktiviert wird ohne CORP-Vorbereitung?

Ohne vorherige CORP-Prüfung aller eingebetteten Ressourcen werden nach COEP-Aktivierung zahlreiche externe Ressourcen blockiert: Bilder von CDNs ohne CORP-Header erscheinen nicht mehr, iFrames von YouTube oder Vimeo werden geblockt, externe Skripte ohne CORS-Header laden nicht. Die Seite kann unbenutzbar werden.

Der empfohlene Ansatz: Zunächst COEP: unsafe-none mit Reporting-Endpoints konfigurieren, um CORP-Violations zu erfassen, ohne sie zu erzwingen. Erst nach vollständiger Behebung aller Violations auf require-corp wechseln.

Häufige Fragen

Warum wurde SharedArrayBuffer deaktiviert? Nach dem Spectre-Angriff 2018 zeigten Forscher, dass hochauflösende Timer (die durch SharedArrayBuffer leicht erzeugbar sind) Timing-Angriffe ermöglichen, mit denen Speicherinhalte anderer Browser-Tabs gelesen werden können. Browser deaktivierten daraufhin SharedArrayBuffer und reduzierten Timer-Präzision. Cross-Origin Isolation ist das offizielle Gegenmodell: Eine isolierte Seite hat keinen Zugriff auf fremde Kontexte, deshalb darf sie wieder präzise Timer nutzen.

Was ist der Unterschied zwischen COEP und CSP?HSTS und CSP (Content Security Policy) schränken ein, welche Ressourcen geladen werden dürfen (URL-basiert). COEP operiert auf Ebene der Cross-Origin-Isolation und prüft, ob Ressourcen eine explizite Einwilligung zum cross-origin Einbetten signalisiert haben.

Kann ich COEP nur für bestimmte Seiten aktivieren? Ja. COEP ist ein per-Response-Header — er gilt nur für die Seite, die ihn sendet, nicht site-weit. Eine Unterseite mit WebAssembly kann COEP haben, während der Rest der Site normal bleibt.

Verwandte Begriffe