Cross-Origin Embedder Policy Checker

Check Cross-Origin-Embedder-Policy and understand which embedded resources must carry CORP or CORS headers before it can be enforced.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Address to check Reads the response headers of a public page.

What COEP does, and what it costs

Cross-Origin-Embedder-Policy requires that every cross-origin resource a document loads has explicitly opted in to being embedded. With require-corp, an image, font, script or frame from another origin loads only if it sends Cross-Origin-Resource-Policy or proper CORS headers. Anything that does not is blocked.

That is a real constraint, and it is the reason this header is worth thinking about before setting. On a site with third-party fonts, embedded video, advertising or analytics, turning on require-corp without measuring first will break a visible part of the page.

Why anyone accepts that cost

COEP is not primarily a defence in its own right. Its purpose is to let the browser guarantee that nothing cross-origin is in your process without permission - which is the precondition for re-enabling SharedArrayBuffer and high-resolution timers, both of which were disabled across the web in response to Spectre. If your application needs those, this is the price.

If it does not, not setting COEP is a defensible decision, and this tool rates its absence as low severity for exactly that reason.

credentialless is usually the better option

Cross-Origin-Embedder-Policy: credentialless achieves the same isolation with far less breakage. Instead of refusing cross-origin resources that have not opted in, it loads them without credentials - no cookies, no client certificates. Public assets continue to work; only resources that genuinely need cookies are affected. For most sites this is the setting to try first.

The mistake this tool looks for

COEP without COOP is the configuration worth catching. Cross-origin isolation requires both headers. Setting COEP alone imposes the entire cost - every cross-origin resource must opt in or it will not load - and delivers none of the benefit, because SharedArrayBuffer and precise timers stay disabled without COOP: same-origin.

It is a common state, usually arrived at by following a guide halfway or by one team setting COEP while another owns COOP. This check reads both headers and reports that combination explicitly rather than assessing COEP in isolation.

Rolling it out

Deploy Cross-Origin-Embedder-Policy-Report-Only: require-corp. Nothing breaks; blocked resources are reported.
Read the reports. Every cross-origin resource that appears needs CORP or CORS headers from its origin, or needs replacing.
For third-party resources you do not control, ask the provider or serve a copy yourself.
Try credentialless before require-corp - it usually clears most of the list.
Add Cross-Origin-Opener-Policy: same-origin, or isolation will not happen at all.

Confirm the result with Cross-Origin Isolation Checker and generate a consistent set with Cross-Origin Policy Generator.

Frequently asked questions

Do I need COEP at all?

Only if you need SharedArrayBuffer, high-resolution timers, or the measurement APIs that depend on cross-origin isolation. If you do not, leaving it unset is a reasonable decision and this tool rates it accordingly.

What is the difference between require-corp and credentialless?

require-corp refuses cross-origin resources that have not opted in. credentialless loads them without cookies or credentials instead of refusing them. credentialless breaks far less and achieves the same isolation, so it is usually the better first choice.

I set COEP and nothing changed. Why?

Almost certainly because COOP is not set to same-origin. Isolation needs both headers, and COEP alone gives you the restrictions without the capabilities. This tool reports that case directly.

Will COEP break my embedded YouTube video or ads?

require-corp very likely will, unless the provider sends the necessary headers. Measure with the report-only header before enforcing, and try credentialless, which handles most public embeds.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.