What Does “Cross-Origin-Embedder-Policy Header Missing” Mean?

How Scanners Detect This Finding

A COEP scanner can report that the header is missing or invalid, but it cannot safely choose the value for you. require-corp changes which cross-origin resources the browser will load and therefore has a much larger compatibility surface than a simple informational response header.

Review COEP, COOP, and CORP findings together for architecture, but remediate them separately. COEP expresses the embedding document’s requirements; CORP expresses a resource’s sharing policy; COOP controls top-level browsing context separation.

Practical Security Scenario

An application wants SharedArrayBuffer or another capability available only in a cross-origin isolated context. It deploys COOP same-origin and COEP require-corp. The browser now refuses to load a third-party image or script that does not provide compatible CORP or CORS permission.

The broken dependency is not necessarily malicious; it simply does not participate in the new isolation contract. The application must either change the dependency, configure the resource owner to opt in, use a suitable request mode, or reconsider whether cross-origin isolation is required on that route.

Where This Control Should Be Applied

COEP is most relevant for browser documents that need a strong resource-isolation model. Do not enable it across an entire site merely because a low-severity scanner alert exists if the business application has no isolation requirement and depends heavily on uncontrolled third-party resources.

When COEP is required, map every dependency by origin and request mode. Include workers, WebAssembly, scripts, fonts, images, media, analytics, maps, payment components, identity providers, and support widgets. This dependency map becomes the rollout checklist.

Why COEP Matters

COEP helps a page create a stronger isolation boundary around the resources it embeds. With require-corp, cross-origin no-cors resources generally need to opt in to being embedded through Cross-Origin-Resource-Policy, while CORS-mode resources must pass CORS.

Together with Cross-Origin-Opener-Policy: same-origin, a suitable COEP policy is part of creating a cross-origin isolated document. Cross-origin isolation is required for certain powerful browser capabilities such as SharedArrayBuffer and high-resolution timing behavior.

The policy is therefore more than a scanner checkbox. It changes the page’s resource-loading contract and should be treated as an architecture change when the application depends on many third-party origins.

COEP Directive Choices

• unsafe-none: The default behavior; no special embedder restriction is requested.
• require-corp: Requires cross-origin no-cors resources to grant compatible permission, commonly through CORP.
• credentialless: Allows a different cross-origin isolation model for certain no-cors requests by omitting credentials; evaluate browser support and application semantics.
• CORS requests: Resources requested in CORS mode remain governed by CORS rather than CORP alone.
• COOP pairing: Cross-origin isolation typically requires COOP same-origin together with COEP require-corp or credentialless.

Related Ammune guides: Cross-Origin-Resource-Policy Header Missing, Cross-Origin-Opener-Policy Header Missing, and CORS Misconfiguration.

A Cross-Origin Isolation Pair

A page that has validated all dependencies may use:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Common Remediation Mistakes

• Adding require-corp globally without inventorying analytics, tag managers, fonts, images, maps, identity widgets, payment frames, workers, or CDNs.
• Assuming COEP alone creates cross-origin isolation; COOP is also part of the common requirement.
• Confusing COEP with CORS. COEP is a document embedding policy; CORS is a cross-origin response access protocol.
• Using CORP cross-origin indiscriminately on private resources just to satisfy COEP.
• Failing to test authenticated third-party resources whose behavior changes under credentialless mode.
• Treating a scanner’s low-risk finding as justification for breaking a production application with no feature or threat requirement.

How to Fix a Missing COEP Header Without Breaking Resources

1. Map every cross-origin dependency. Inventory scripts, images, fonts, media, iframes, workers, analytics, payment widgets, identity providers, CDNs, and any resource fetched from another origin.

2. Choose require-corp or credentialless deliberately. require-corp expects eligible no-cors subresources to opt in through CORP; credentialless can allow certain no-cors cross-origin resources without explicit CORP while omitting credentials. Review browser support before relying on either behavior.

3. Fix third-party resource participation. For resources you control, send an appropriate CORP header or request them in CORS mode where that is the correct model. For third-party resources, confirm the provider supports the needed policy before enforcement.

4. Use report-only/observation where supported. COEP reporting mechanisms can help surface violations before broad enforcement. Exercise representative user journeys and distinguish essential resources from stale dependencies.

5. Verify the isolation objective. If cross-origin isolation is the goal, pair COEP with an appropriate COOP policy and test window.crossOriginIsolated. Re-run ZAP 90004 and evaluate CORP and COOP findings independently.

Configuration Examples

COEP should normally be owned by the layer that understands document-level requirements. If only selected application areas need cross-origin isolation, avoid a blanket gateway rule that applies the same policy to every HTML response.

add_header Cross-Origin-Embedder-Policy "require-corp" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;

Header always set Cross-Origin-Embedder-Policy "require-corp"
Header always set Cross-Origin-Opener-Policy "same-origin"

Apply COEP only to routes whose cross-origin dependencies have been mapped and validated. Route-specific rollout is often safer than a site-wide switch.

How to Test the Fix

1. Inventory every cross-origin resource used by the page and note whether it is requested with CORS or no-cors semantics.
2. Enable COEP in a non-production environment and watch browser console errors for blocked dependencies.
3. For require-corp, confirm cross-origin no-cors resources send an appropriate Cross-Origin-Resource-Policy value.
4. If cross-origin isolation is required, verify both the COOP header and window.crossOriginIsolated.
5. Test sign-in, payments, maps, analytics, workers, downloads, media, fonts, and support widgets before production rollout.

Open critical pages with browser developer tools and watch for blocked subresource loads, credential changes, or iframe failures. Test authentication, payments, analytics, media, fonts, workers, and third-party scripts. When cross-origin isolation is intended, verify crossOriginIsolated === true rather than checking header presence alone.

How to Think About Severity

ZAP rates 90004-2 as Low and the rule is beta. Absence of COEP is not automatically an exploitable vulnerability; many applications do not require cross-origin isolation. The finding is more meaningful when the application uses powerful features that depend on isolation or when stronger control over embedded cross-origin resources is part of the design.

Operational risk can run in the opposite direction: enabling COEP too aggressively can break critical third-party dependencies. Treat remediation as an architecture change with browser testing, not as a one-line compliance toggle.

How Ammune Fits

COEP decides which cross-origin resources a browser document may embed under its policy. Ammune evaluates runtime API traffic and application behavior beyond the browser isolation boundary.

That separation matters for modern web applications: a page can be fully cross-origin isolated while its APIs still expose excessive data, accept abusive automation, or contain authorization flaws. Isolation reduces one browser attack surface; API protection addresses what happens at the service boundary.

Production Remediation Checklist

• Inventory all cross-origin subresources and embedded frames before enabling COEP.
• Choose require-corp or credentialless based on actual resource and credential needs.
• Ensure controlled third-party resources opt in via CORP or CORS where required.
• Review browser compatibility for the chosen COEP value and application clients.
• Use reporting/observation mechanisms during rollout when available.
• Test authentication, payment, analytics, fonts, media, workers, and iframe flows.
• Pair COEP with an appropriate COOP policy when cross-origin isolation is required.
• Verify window.crossOriginIsolated for isolation-dependent features.
• Re-run ZAP 90004-2 and investigate CORP/COOP alerts independently.
• Keep an owned inventory of third-party resources so future changes do not silently break enforcement.

Frequently Asked Questions

Primary References