Home / Knowledge hub / Cross-Origin-Embedder-Policy
Knowledge hub
Cross-Origin-Embedder-Policy
A header requiring embedded resources to opt in before your page will load them.
What it means
Cross-Origin-Embedder-Policy, or COEP, is an HTTP response header that controls whether a page may load resources from other origins. With the require-corp value, a cross-origin image, script or frame loads only if the other side has opted in, through a Cross-Origin-Resource-Policy header or CORS.
The default value, unsafe-none, keeps today's open behaviour. A third value, credentialless, loads cross-origin resources without sending cookies, so many of them can load without opting in.
Why it matters
Its main job is to make a page cross-origin isolated. Together with Cross-Origin-Opener-Policy set to same-origin, it puts the page in a process of its own, which browsers require before they expose powerful features such as SharedArrayBuffer and high-resolution timers.
That isolation also limits what a malicious page could learn from your content through side channels such as Spectre. For most business sites it is a hardening step, not an emergency, but it matters if you handle sensitive data in the browser.
How it shows up
You meet it when a performance feature asks for isolation, or when a security review lists it among the response headers to set. It is sent by the web server or CDN on the page, and it affects everything that page embeds.
The mistakes repeat. Turning it on breaks images, fonts, ads or widgets from other hosts that never set the needed header. Teams then weaken it or drop it. Try it in report-only mode first, list what fails, and ask the third party for the resource header, or use credentialless where that fits.
Questions people ask
Cross-Origin-Embedder-Policy, answered
What does require-corp mean?
The page may only load cross-origin resources that explicitly allow it, through a CORP header or CORS. Anything else is blocked.
It is the strict choice, and the one that most often breaks third-party content.
Is COEP the same as CORS?
No. CORS lets a site share responses with a script on another origin. COEP is the embedding page's rule that it will only load cross-origin resources that agree to be loaded.
They can work together, since a CORS response counts as opting in.
Do we need it?
Only if you need cross-origin isolation, for example for SharedArrayBuffer, or you want extra protection from side-channel attacks on a sensitive app. Most sites do not need it today.
Add it deliberately, with testing.
Can we test it without breaking the site?
Yes. Send Cross-Origin-Embedder-Policy-Report-Only first and collect reports of what would be blocked. Fix or replace the failing resources, then switch to the enforcing header.
This mirrors the approach used with CSP report-only.
Does COEP replace the same-origin policy?
No. The same-origin policy still applies. COEP adds a stricter condition on what your page chooses to embed, mainly to support isolation.
It is one extra layer, not a substitute.
Sources
Where this comes from
Related
Terms that sit next to this one
Cross-Origin-Opener-Policy
A header that isolates your page from windows opened by other sites.
Security headers
Response headers that switch on browser protections against common web attacks.
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
CORS
The browser rule for which sites may read responses from your API.
CSP report-only mode
Trying a content security policy by logging breaches without blocking anything.
What does your page load from elsewhere?
Security headers help, and the flaws behind them still need finding. We find vulnerabilities in your web app and its APIs and prove each by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.