Cross-Origin-Embedder-Policy-Report-Only security response

What it does

Cross-Origin-Embedder-Policy-Report-Only lets you monitor which cross-origin resources would be blocked under a Cross-Origin-Embedder-Policy: require-corp policy — without actually blocking anything. It's the safe rollout mechanism for COEP: since enabling COEP for real can silently break third-party resources (fonts, analytics, embedded widgets) that haven't opted in via CORP or CORS, this report-only mode lets you collect violation data first, fix what needs fixing, and only then flip to actual enforcement.

Syntax

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

Same value options as the enforcing header (unsafe-none, require-corp, credentialless), but paired with a report-to group (defined via the Report-To header or the newer Reporting API) to actually collect the violation reports somewhere useful.

How the audit workflow works

1. Deploy Cross-Origin-Embedder-Policy-Report-Only: require-corp alongside a configured reporting endpoint — nothing on the page actually breaks yet.
2. Real user traffic (or your own QA testing) triggers reports for every cross-origin resource that would have been blocked under enforcement.
3. Review the collected reports, identify which third-party resources need CORP/CORS fixes (or need to be dropped/replaced).
4. Fix what you can control directly, work with third-party providers on what you don't, and re-test.
5. Once reports come back clean, switch to the real enforcing header: Cross-Origin-Embedder-Policy: require-corp.

This staged rollout is exactly the pattern CSP's Content-Security-Policy-Report-Only established — apply the same "monitor, fix, enforce" discipline rather than flipping straight to enforcement and hoping nothing breaks.

Common mistakes and gotchas

Skipping this step entirely and enabling enforcement directly. COEP's require-corp mode is genuinely disruptive if your page depends on any uncooperative third-party resources — going straight to enforcement without first auditing via report-only is the single most common way teams end up with a broken production page after enabling COEP.

Not actually configuring a reporting endpoint. Setting the report-only header without a working report-to destination means violations happen but nowhere records them — you'll see console warnings in your own browser during manual testing, but won't get aggregate data from real user traffic, which matters for catching issues that only show up in specific browsers or user configurations.

Assuming report-only mode has zero effect on the page. It doesn't block resources, but it does still evaluate every cross-origin load against the policy to generate reports — this is a negligible but non-zero overhead, worth being aware of even though it's not a practical performance concern.

Forgetting to also test Cross-Origin-Opener-Policy alongside it. Since full cross-origin isolation requires both COEP and COOP together, auditing COEP in isolation doesn't tell you whether your COOP configuration is also compatible — test both together if your actual goal is enabling crossOriginIsolated.

Real-world examples

Auditing before enabling enforcement:

HTTP/1.1 200 OK
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep-endpoint"
Report-To: {"group":"coep-endpoint","max_age":86400,"endpoints":[{"url":"https://example.com/reports/coep"}]}

After confirming no violations, switching to enforcement:

HTTP/1.1 200 OK
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

FAQ

Does Cross-Origin-Embedder-Policy-Report-Only block any resources?

No — it only generates violation reports for what would be blocked under real enforcement. The page continues to load all resources normally while you're in report-only mode.

How long should I run in report-only mode before enforcing?

Long enough to capture representative real-world traffic across different browsers, user configurations, and any cached third-party resources — a single QA pass often misses issues that only surface under specific conditions, so monitoring real production traffic for at least a few days is generally more reliable than relying solely on manual testing.

Can I run report-only and enforcing COEP at the same time?

Yes — you can send both headers simultaneously, using the report-only version to monitor for a stricter policy than what you're currently enforcing, letting you evaluate tightening your policy further without disrupting current behavior.

Where do the violation reports actually go?

Wherever you configure via the report-to directive and a corresponding Report-To header (or the newer Reporting API Reporting-Endpoints header) — you need your own endpoint or a third-party reporting service to actually receive and store these reports.

Fun fact

The report-only pattern (paired enforcing + monitoring header variants) has become such a standard web security practice that it now appears across multiple unrelated header families — CSP, COEP, and COOP all have this exact same "ship the report-only version first, audit, then enforce" workflow. It's a rare case of a rollout methodology becoming so proven that browser vendors started baking the pattern directly into new security headers by default, rather than leaving teams to invent their own staged-rollout process each time.