Cross-Origin-Embedder-Policy
Send `Cross-Origin-Embedder-Policy: require-corp` to demand that every cross-origin resource explicitly opts in to being loaded — needed for cross-origin isolation, and it will break embeds that have not.
Correct for some sites and disruptive for others. Read what it breaks before deploying.
What it does
COEP inverts the default for subresources. Normally your page can load an image, script or font from any origin that serves it. With `require-corp`, every cross-origin resource must explicitly consent — by sending `Cross-Origin-Resource-Policy: cross-origin`, or by being fetched with CORS — and anything that does not is blocked.
The reason to accept that is cross-origin isolation. Paired with COOP `same-origin`, it moves your document into a context where the browser is confident no cross-origin data is present in the process, which is what unlocks `SharedArrayBuffer`, `performance.now()` at full resolution, and the WebAssembly threading that depends on them.
`credentialless` is the cheaper variant: instead of demanding that each resource opt in, it strips credentials from cross-origin no-CORS requests. Third-party resources load without cookies, which is often fine for fonts, images and analytics, and avoids chasing every vendor for a CORP header. It is the value to reach for first if you need isolation but do not control your subresources.
What to send
No default — this header should be sent only when a specific requirement calls for it.
There is no value to send by default — COEP is worth deploying only if you need cross-origin isolation for `SharedArrayBuffer`, WebAssembly threads or precise timers. If you do, start with `credentialless` and fall back to `require-corp` only where you control every embedded origin. If you do not, sending it buys nothing and breaks embeds.
Directives and values
The default. Cross-origin subresources load as normal with no opt-in required.
Every cross-origin subresource must send `Cross-Origin-Resource-Policy` or be fetched with CORS, or it is blocked. The strictest value, and the one with the largest blast radius.
Cross-origin no-CORS requests are sent without cookies or credentials rather than being blocked. Achieves isolation without requiring every third party to cooperate — at the cost of those resources no longer being authenticated.
`Cross-Origin-Embedder-Policy-Report-Only` lists which subresources would be blocked. Essential — the list is always longer than expected.
Common mistakes
- Enabling it without needing cross-origin isolation. COEP has no standalone security benefit worth the breakage. If nothing in the application uses `SharedArrayBuffer`, WASM threads or high-resolution timing, the correct value is the default.
- Choosing require-corp when you do not control the subresources. Every third-party font, image, script, analytics beacon and embedded video must cooperate. If any vendor will not send CORP, that resource simply stops loading. `credentialless` avoids the negotiation entirely.
- Forgetting that iframes must opt in too. Under `require-corp`, an embedded document needs its own COEP header to be framed. A third-party iframe that does not send one is blocked, which is frequently how a working page becomes a blank rectangle.
- Deploying it without COOP. COEP alone does not produce an isolated context. `crossOriginIsolated` stays false, the APIs stay unavailable, and you have taken on all the breakage for none of the benefit.
Browser support
Supported in current Chromium browsers and Firefox; `credentialless` has narrower support than `require-corp`, notably in Safari, so a site relying on it should verify `crossOriginIsolated` at runtime rather than assuming. Browsers without support ignore the header and simply do not grant isolation.
Frequently asked questions
Do I need Cross-Origin-Embedder-Policy?
Only if you need cross-origin isolation — that is, `SharedArrayBuffer`, WebAssembly threads, or full-resolution timers. COEP provides no meaningful protection on its own and blocks cross-origin resources that have not opted in, so without that requirement the default is the right value.
What is the difference between require-corp and credentialless?
`require-corp` blocks any cross-origin subresource that does not explicitly opt in via CORP or CORS. `credentialless` instead loads them without cookies or credentials, so third parties need not cooperate. `credentialless` is far easier to deploy but has narrower browser support.
Why did my embeds break after enabling COEP?
Under `require-corp`, every cross-origin resource — including framed documents — must send `Cross-Origin-Resource-Policy` or be fetched with CORS. Anything that does not is blocked. Run `Cross-Origin-Embedder-Policy-Report-Only` first to get the full list before enforcing.
How do I check whether cross-origin isolation is active?
Read `window.crossOriginIsolated` in the page. It is true only when COOP is `same-origin` and COEP is `require-corp` or `credentialless`, and both have been honoured by the browser.
The free Security Headers Checker reads Cross-Origin-Embedder-Policy from a live response and grades it alongside every other header on this reference — no account needed.
For the longer treatment, read Advanced HTTP Security Headers: A Deep Dive in the Learning Center.
Related headers
Severs the link between your page and windows that opened it. Required for cross-origin isolation — and it breaks popup flows.
Declares who may load your resources at all. Blocks side-channel reads that CORS does not cover.
The most powerful and most misconfigured security header. Most deployed policies provide no XSS protection at all.