Cross-Origin Embedder Policy (COEP)
What is 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.
● Examples
- 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.
● Frequently asked questions
What is 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. It belongs to the Application Security category of cybersecurity.
What does Cross-Origin Embedder Policy (COEP) mean?
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.
How does Cross-Origin Embedder Policy (COEP) work?
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.
How do you defend against Cross-Origin Embedder Policy (COEP)?
Defences for Cross-Origin Embedder Policy (COEP) typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Cross-Origin Embedder Policy (COEP)?
Common alternative names include: COEP.
● Related terms
- 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)
A browser-enforced mechanism that lets a server selectively relax the Same-Origin Policy so that JavaScript on one origin can read responses from another.
- appsec№ 237
Content Security Policy (CSP)
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
- appsec№ 552
HTTP Security Headers
Response headers that instruct browsers to enforce defensive behaviour such as HTTPS-only, framing restrictions, content policies and referrer controls.
- appsec№ 1164
Site Isolation
A Chromium security architecture that places documents from different sites into separate operating-system processes so a compromised renderer cannot read cross-site data.
- vulnerabilities№ 1192
Spectre
A family of microarchitectural attacks that abuse CPU speculative execution to leak data across security boundaries via cache-based side channels.
● See also
- № 911Permissions-Policy