Cross-Origin Embedder Policy (COEP)
Was ist Cross-Origin Embedder Policy (COEP)?
Cross-Origin Embedder Policy (COEP)An HTTP response header that forces every cross-origin subresource a document loads to explicitly opt in via CORS or CORP, completing the cross-origin isolation prerequisites alongside COOP.
Cross-Origin Embedder Policy (`Cross-Origin-Embedder-Policy`) is a browser security header that controls whether a document is allowed to embed cross-origin subresources without an explicit opt-in. With `require-corp`, every image, script, iframe, font, or other cross-origin asset must carry either a CORS response (`Access-Control-Allow-Origin`) or a Cross-Origin-Resource-Policy (CORP) header that authorizes the embed; otherwise the load fails. With `credentialless`, cross-origin requests for no-CORS resources are sent without cookies and treated as anonymous. COEP exists primarily to enable cross-origin isolation: when paired with `Cross-Origin-Opener-Policy: same-origin`, it unlocks high-resolution timers, `SharedArrayBuffer`, and other features that were restricted to mitigate Spectre. Deploying COEP often requires auditing third-party assets to ensure they ship `Cross-Origin-Resource-Policy: cross-origin` or proper CORS.
● Beispiele
- 01
A WebAssembly-heavy app sends `Cross-Origin-Embedder-Policy: require-corp` and `Cross-Origin-Opener-Policy: same-origin` to re-enable `SharedArrayBuffer`.
- 02
A CDN that serves third-party scripts adds `Cross-Origin-Resource-Policy: cross-origin` so its assets remain embeddable in COEP-enforcing pages.
● Häufige Fragen
Was ist Cross-Origin Embedder Policy (COEP)?
An HTTP response header that forces every cross-origin subresource a document loads to explicitly opt in via CORS or CORP, completing the cross-origin isolation prerequisites alongside COOP. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet Cross-Origin Embedder Policy (COEP)?
An HTTP response header that forces every cross-origin subresource a document loads to explicitly opt in via CORS or CORP, completing the cross-origin isolation prerequisites alongside COOP.
Wie funktioniert Cross-Origin Embedder Policy (COEP)?
Cross-Origin Embedder Policy (`Cross-Origin-Embedder-Policy`) is a browser security header that controls whether a document is allowed to embed cross-origin subresources without an explicit opt-in. With `require-corp`, every image, script, iframe, font, or other cross-origin asset must carry either a CORS response (`Access-Control-Allow-Origin`) or a Cross-Origin-Resource-Policy (CORP) header that authorizes the embed; otherwise the load fails. With `credentialless`, cross-origin requests for no-CORS resources are sent without cookies and treated as anonymous. COEP exists primarily to enable cross-origin isolation: when paired with `Cross-Origin-Opener-Policy: same-origin`, it unlocks high-resolution timers, `SharedArrayBuffer`, and other features that were restricted to mitigate Spectre. Deploying COEP often requires auditing third-party assets to ensure they ship `Cross-Origin-Resource-Policy: cross-origin` or proper CORS.
Wie schützt man sich gegen Cross-Origin Embedder Policy (COEP)?
Schutzmaßnahmen gegen Cross-Origin Embedder Policy (COEP) kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Cross-Origin Embedder Policy (COEP)?
Übliche alternative Bezeichnungen: COEP.
● Verwandte Begriffe
- appsec№ 263
Cross-Origin Opener Policy (COOP)
An HTTP response header that lets a document opt into a process-isolated browsing context group, preventing cross-origin windows from inspecting or manipulating it via `window.opener` and friends.
- appsec№ 246
CORS (Cross-Origin Resource Sharing)
Vom Browser durchgesetzter Mechanismus, mit dem ein Server die Same-Origin Policy gezielt lockern kann, damit JavaScript einer Origin Antworten einer anderen lesen darf.
- appsec№ 237
Content Security Policy (CSP)
HTTP-Antwort-Header, der dem Browser mitteilt, welche Quellen für Skripte, Styles, Frames und andere Inhalte erlaubt sind, und so XSS- und Datendiebstahlangriffe begrenzt.
- appsec№ 552
HTTP-Sicherheitsheader
Antwort-Header, die den Browser zu defensivem Verhalten anweisen: HTTPS-Pflicht, Framing-Beschränkungen, Inhaltsrichtlinien und Referer-Kontrolle.
- appsec№ 1164
Site Isolation
Chromium-Sicherheitsarchitektur, die Dokumente unterschiedlicher Sites in separate Betriebssystemprozesse legt, sodass ein kompromittierter Renderer keine fremden Daten lesen kann.
- vulnerabilities№ 1192
Spectre
Familie microarchitektonischer Angriffe, die spekulative Ausführung von CPUs missbrauchen, um Daten über Cache-Seitenkanäle über Sicherheitsgrenzen hinweg zu leaken.
● Siehe auch
- № 911Permissions-Policy