Cross-Origin-Embedder-Policy Requires Resource Opt-In

A page can pull scripts, images, fonts, workers, frames, and other resources from origins outside its own. Those dependencies often cross an administrative boundary as well as an origin boundary. Cross-Origin-Embedder-Policy (COEP) lets a document require stronger conditions before the browser loads cross-origin resources into its context.

The common restrictive value is:

Cross-Origin-Embedder-Policy: require-corp

With require-corp, a cross-origin resource loaded without CORS must explicitly permit the embedding context through Cross-Origin Resource Policy (CORP). Resources fetched in CORS mode can instead satisfy the relevant CORS checks.

COEP is therefore an embedder policy, not a declaration that every remote resource is trusted. It changes admission conditions for resources; application code still needs its normal integrity, authorization, and content controls.

require-corp changes the default for no-CORS resources

Many HTML elements can issue requests in no-cors mode. Without COEP, a browser can load eligible cross-origin resources even when their response does not carry a CORP header.

A document can tighten that behavior:

Cross-Origin-Embedder-Policy: require-corp

A cross-origin resource intended for that document can opt in with a suitable CORP response, for example:

Cross-Origin-Resource-Policy: cross-origin

A resource owner can choose a narrower CORP value when its deployment permits it. The correct value belongs to the resource response, because the resource owner is declaring where the response may be used under CORP semantics.

This division matters operationally. Adding COEP to an application can expose dependencies that previously worked only because the browser accepted their default cross-origin loading behavior.

CORS and CORP are separate admission paths

COEP does not turn CORP into CORS. The mechanisms answer different questions.

A resource requested in CORS mode can be admitted when the CORS exchange succeeds. For a script module, API fetch, or another CORS-enabled request, the server’s Access-Control-Allow-Origin response participates in that decision.

A no-cors resource under require-corp needs an applicable CORP policy. For example:

<img src="https://media.example/banner.png" alt="">

If that image is fetched without CORS and the response lacks a compatible CORP header, COEP can block its use by the document.

Changing the request to CORS mode is not a cosmetic fix. The remote server must support the CORS request and return the required response headers. A deployment plan should classify each dependency by request mode rather than adding headers at random.

Credentialless changes no-CORS credential handling

COEP also defines the credentialless value:

Cross-Origin-Embedder-Policy: credentialless

For cross-origin requests made in no-cors mode, this policy omits credentials. In return, such responses do not need an explicit CORP opt-in merely to satisfy COEP. Requests using other modes continue to follow their normal CORS rules.

That tradeoff can fit public resources that do not depend on cookies or HTTP authentication. It is not equivalent to require-corp, and it can break resources whose response varies according to credentials.

Before selecting credentialless, inspect whether a dependency expects cookies, client identity, personalized content, or authenticated redirects. A resource that appears static at one URL may still sit behind credential-sensitive infrastructure.

COEP is one half of cross-origin isolation

A document that needs a cross-origin isolated environment commonly combines COEP with a compatible Cross-Origin Opener Policy:

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

COOP and COEP protect different boundaries. COOP governs top-level opener relationships and browsing context groups. COEP governs cross-origin resource admission for the embedding document.

When the surrounding requirements are satisfied, the browser can expose crossOriginIsolated as true:

if (crossOriginIsolated) {
  // Code may use APIs gated on cross-origin isolation.
}

The boolean should be checked at runtime when application behavior depends on it. Seeing one header in server configuration does not establish the complete browser state.

Third-party dependencies become part of the rollout

COEP deployment often fails at the dependency edge rather than in first-party code. Analytics scripts, media hosts, font services, worker scripts, embedded tools, and CDN assets may each have different request modes and response headers.

Build an inventory from actual network traffic. For every cross-origin dependency, record the URL pattern, request mode, credential mode, redirect chain, and final response headers. Redirects deserve attention because the final resource must still satisfy the policy that applies to the request.

A resource controlled by another organization may not offer the needed CORS or CORP response. In that case, the application must change the integration, use a compatible endpoint, or avoid enabling a policy that the dependency cannot satisfy. Proxying a third-party resource through the application origin also transfers caching, security, availability, and content-validation responsibilities to that application.

Report-only mode can expose breakage before enforcement

COEP has a report-only counterpart:

Cross-Origin-Embedder-Policy-Report-Only: require-corp

Report-only deployment can help identify resources that would conflict with the intended policy without immediately enforcing the restriction. Reporting still needs appropriate reporting configuration and browser support.

Treat reports as evidence, not as a complete dependency inventory. Exercise real application paths, including authenticated areas, lazy-loaded interfaces, worker startup, error pages, and infrequent administrative flows.

Once enforcement is enabled, inspect the final response after CDN and reverse-proxy processing. A header present in application code but removed or replaced upstream does not create the intended browser policy.

Keep resource ownership explicit

COEP works best when resource ownership and embedding intent are visible in HTTP responses. require-corp asks cross-origin dependencies to arrive through successful CORS or explicit CORP policy. credentialless offers a different boundary for eligible no-CORS requests by removing credentials.

Neither mode validates the contents of a permitted resource. A compromised third-party script remains dangerous if the application intentionally loads and executes it. Subresource Integrity, CSP, origin separation, dependency review, and application authorization address other parts of that risk.

The useful property is narrower: cross-origin embedding stops being an ambient assumption. Each dependency must fit a request and response path that the browser can admit under the document’s policy.

References

Cybersecurity Web Security Browser Security HTTP Headers