Cross-Origin-Embedder-Policy (COEP), what it does and how to set it

COEP requires cross-origin resources to opt in before a document can load them, and with COOP enables cross-origin isolation.

Cross-Origin-Embedder-Policy (COEP) requires that every cross-origin resource a document loads explicitly opts in, through CORP or CORS. That stops a page from silently pulling in cross-origin data, and together with COOP it puts the document into the cross-origin isolated state needed for SharedArrayBuffer and high-resolution timers.

The safe configuration is a single header line:

Cross-Origin-Embedder-Policy: require-corp

How COEP works

With require-corp, every cross-origin subresource the page loads must carry a Cross-Origin-Resource-Policy header (or pass a CORS check); anything that does not opt in is blocked. The alternative value, credentialless, takes a different route: it loads cross-origin resources without credentials (no cookies) instead of requiring them to opt in, which is easier to adopt but weaker.

How to configure COEP

Value	Status	Effect
`unsafe-none`	❌ Risky	The default. No requirement; cross-origin resources load as usual.
`require-corp`	✅ Good	Every cross-origin resource must opt in via CORP or CORS, or it is blocked. Widely supported.
`credentialless`	🧪 Experimental	Cross-origin resources load without credentials instead of opting in. In Chrome and Firefox; not Safari.

Report-only mode

Reporting-Endpoints: coep-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep-endpoint"

Report-Only lists every embed that would break under require-corp without actually blocking it, which is essential because COEP is the hard part of a cross-origin isolation rollout.

What it protects against

Silent cross-origin embedding, and the data exposure it enables, is the threat COEP addresses: it forces every cross-origin resource to consent to being loaded. It is also the prerequisite for safe cross-origin isolation, which the browser only grants when embedding is locked down.

Insecure configurations to avoid

unsafe-none is the default and enforces nothing. Cross-origin isolation needs require-corp (or credentialless) plus Cross-Origin-Opener-Policy: same-origin.

Sending COEP without the matching Cross-Origin-Opener-Policy: same-origin gives you neither isolation nor the features that depend on it, a common dead end.

Known bypasses and limitations

COEP needs every cross-origin subresource to cooperate (send CORP or pass CORS), so it can be hard to roll out on a page with many third parties that have not adopted it. The credentialless value eases this but is not supported in Safari.

Risks

Enforcing require-corp blocks every non-cooperating embed at once, which can take out fonts, analytics, or iframes that do not send CORP. Use Report-Only to find them and fix or replace them before enforcing.

Recommendation

Cross-Origin-Embedder-Policy: require-corp

The OWASP HTTP Headers cheat sheet recommends require-corp. Where Safari support is not a requirement, web.dev documents credentialless as the lower-friction path, since third parties do not have to opt in. On the resources you serve yourself, set Cross-Origin-Resource-Policy: same-site (also OWASP) so your own subresources keep loading under require-corp.

Reporting

Add a report-to="..." parameter, declare the endpoint, and the browser emits the coep report for each blocked resource. CentralCSP collects the coep stream.

Browser support

Standard in the HTML Living Standard; require-corp is broadly supported across current Chrome, Firefox, and Safari. credentialless is supported in Chrome and Firefox but not Safari, so it is not a complete cross-browser solution on its own. The report-to parameter is Chromium-only.

FAQ

What is the difference between require-corp and credentialless?

Both are COEP values. require-corp demands that every cross-origin resource opts in through CORP or CORS, or the browser blocks it. credentialless instead loads cross-origin resources without credentials, so no cookies, which is easier to adopt but weaker, and it is not supported in Safari.

How do CORP and COEP work together?

COEP with require-corp requires every cross-origin subresource to opt in; CORP is the header a resource sends to grant that opt-in. On resources you serve yourself, set Cross-Origin-Resource-Policy: same-site so they keep loading under COEP. The CORP vs COEP guide covers the pairing in depth.

Cross-Origin-Embedder-Policy