No Cross-Origin-Embedder-Policy is in force
Updated
What this check looks for
The page has not required embedded resources to opt in to being loaded. This is optional and only matters for specific advanced features.
Why it matters
Nothing is wrong. Setting this is how a page becomes cross-origin isolated, which some measurement and multithreading APIs require — and it is disruptive to enable, because every third-party resource must then opt in.
When the check passes, your report says: “A Cross-Origin-Embedder-Policy restricts what the page may embed”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Web security
- Module
- Web security headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Leave it off unless a page needs cross-origin isolation; if one does, roll it out in report-only mode first.
Enforcing it blocks every third-party resource that has not opted in, in exchange for features most sites never use.
Decide whether any page needs
SharedArrayBuffer, memory measurement or precise timers. If none does, there is nothing to change.If one does, send
Cross-Origin-Embedder-Policy-Report-Only: require-corpon that page with a reporting endpoint, and read what would have been blocked.Ask each third party that appears to send
Cross-Origin-Resource-Policy: cross-originor CORS headers, or replace it; considercredentiallesswhere the blocked resources are public.Switch to the enforcing header, with
Cross-Origin-Opener-Policy: same-origin, only on the pages that need isolation.
How to confirm it worked
On those pages,
self.crossOriginIsolatedin the browser console returns true, and the console shows no blocked resource the page needs.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹detail›
require-corp makes every cross-origin subresource carry Cross-Origin-Resource-Policy or CORS headers, or fail to load. credentialless is the gentler variant that loads them without credentials. unsafe-none is the browser default written out and restricts nothing; it, and a value browsers do not recognise, are reported here exactly as a missing header is. The value is compared exactly, so Require-Corp is unrecognised, and a header sent twice reaches the browser as a list it cannot read as one policy, which falls back to unsafe-none too. Enable it only when you need cross-origin isolation, and audit every third-party resource first.
Cross-origin isolation — this header together with Cross-Origin-Opener-Policy: same-origin — is what unlocks SharedArrayBuffer, performance.measureUserAgentSpecificMemory() and full-precision timers. Those matter to sites running multithreaded WebAssembly, in-browser audio or video processing, or emulators. A site that does none of that gains nothing a visitor would notice, which is why our checker deducts nothing here and our security headers generator leaves the header off unless you choose it.
If you do need it, require-corp blocks every cross-origin image, script, font, stylesheet or frame that does not opt in. Analytics, embedded video, maps, payment frames and hosted fonts are the usual casualties, and the only symptom is a message in the browser console. credentialless sends cross-origin requests that need no CORS without cookies and lets them through, so public resources keep working while anything relying on a logged-in third-party session does not. Browser support for credentialless arrived later than for require-corp and was not universal when this was written in 2026; check current support before relying on it. Every embedded frame must send its own policy for isolation to hold.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.