After adding Cross-Origin-Embedder-Policy: require-corp, previously working CDN images disappear and scripts may be blocked. Opening the resource directly still works, and its response may even be 200. Neither result proves that the resource can be embedded in the protected page.
COEP changes the conditions under which a document loads cross-origin resources. Diagnose the document policy, the resource request mode, and the permission supplied by the resource response together. This guide is for teams deploying cross-origin isolation or browser capabilities that depend on it. Commands and headers are examples, not production test results.
Separate the responsibilities of COEP, CORP, and COOP
| Header | Where to inspect it | Main purpose |
|---|---|---|
| COEP | The document or relevant environment response | Sets conditions for loading cross-origin resources |
| CORP | The resource response | Declares permitted embedding scope for no-cors requests |
| COOP | The top-level document response | Controls browsing context group relationships with other windows |
A common cross-origin isolation configuration combines COOP: same-origin with COEP: require-corp in a secure context. The result also depends on embedding relationships, permissions policy, and browser behavior. Seeing both headers is not sufficient proof that isolation is active.[1][3]
CORS governs permission for cross-origin requests and access to their responses. CORP does not grant JavaScript permission to read a response, and COEP does not automatically add permissions to files hosted on a CDN.
Identify the request that fails and its mode
Preserve one failing load in the Console and Network panel. Record the page URL, complete asset URL, error name, request mode, and final response headers. Check redirects and whether the final hostname differs from the initial address.
Under require-corp, a cross-origin resource requested in no-cors mode generally needs an appropriate CORP response to be embedded. A request made in CORS mode that successfully passes CORS can satisfy the corresponding loading requirement.[1]
Images, classic scripts, and module scripts do not all use the same default request behavior. Module scripts already depend on CORS. If you add a crossorigin attribute, check credential requirements as well: changing request behavior can affect whether a cookie-dependent resource loads.
Start with one image or script rather than changing every response. If the browser reports CSP, MIME, SRI, or mixed-content failures, investigate those separately using the specific error.
Inspect the headers the document and asset actually receive
Save headers and bodies with GET requests rather than assuming that HEAD follows the same path:
curl -sS -D page-headers.txt -o page.html https://www.example.com/ curl -sS -D asset-headers.txt -o sample.png \ https://static.example.net/images/sample.png
Inspect COEP and COOP on the document, then CORP and CORS headers on the resource. curl does not enforce browser security checks. A successful download establishes only that this request received a response; test the final behavior in the actual page.
If edge and origin rules might differ, compare an authorized direct-origin request:
curl -sS --resolve static.example.net:443:203.0.113.10 \ -D origin-headers.txt -o origin-sample.png \ https://static.example.net/images/sample.png
The IP is a documentation address. --resolve retains the URL hostname for Host, TLS SNI, and certificate verification while changing the connection destination. If the origin accepts only CDN traffic, use an approved operational path. Do not expose it publicly or bypass certificate validation with -k.
When the origin returns the intended header but the edge does not, inspect CDN response-header rules, rule precedence, and cached copies. Whether a header is added dynamically at the edge or stored with an object depends on the actual configuration. An origin change does not guarantee an immediate update at every node.
Use resource-side CORP or a successful CORS request as appropriate
For public images or other applicable resources that are intentionally available for embedding by any site, consider a resource response such as:
Cross-Origin-Resource-Policy: cross-origin
This is a resource-side permission. Do not apply it indiscriminately to sensitive files. same-origin restricts use to the same origin; same-site permits the same-site scope. Same-site does not mean every domain owned by one company. A website and an external CDN hostname may not be same-site.[2]
Where CORS loading is appropriate, configure the element explicitly, for example:
<img src="https://static.example.net/images/sample.png" crossorigin="anonymous" alt="Example image">
The resource must also return a CORS response permitting the page’s origin. For genuinely public resources with no cross-origin credential dependency, the following may fit the intended policy:
Access-Control-Allow-Origin: *
Anonymous mode does not send credentials to a cross-origin resource. Cookie-dependent files may instead return a login page or denial response. If credentials are genuinely required, design a precise origin and credentials policy; a wildcard origin is not a repair for credentialed access.
When dynamically returning a specific allowed origin, check Vary: Origin and the CDN cache behavior together. One origin’s response must not be incorrectly reused for another. Blindly reflecting arbitrary Origin values is not a sound access-control design.
Observe response headers with a request such as:
curl -sS -D - -o /dev/null \ -H 'Origin: https://www.example.com' \ https://static.example.net/images/sample.png
This does not reproduce browser CORS enforcement. Ordinary cross-origin resource requests also do not necessarily trigger an OPTIONS preflight.
Evaluate credentialless before switching to it
COEP also supports a credentialless mode. For relevant cross-origin no-cors requests, it changes loading conditions by omitting credentials and applying related behavior. It is not simply a switch that disables security checks. Review target-browser support, request modes, and cookie dependencies before using it.[1]
Authenticated images, third-party components, and hotlink-protection logic may break when credential behavior changes. Credentialless does not remove the checks required by CORS-mode requests, and it does not resolve independent CSP or other restrictions.
If the application does not require cross-origin isolation, first establish why COEP is being enabled. If the product depends on isolation, inventory its dependencies and address each one rather than relying on broad, unexplained policy changes.
Verify isolation as well as popup and embedding behavior
In the Console of the page requiring isolation, inspect:
window.isSecureContext window.crossOriginIsolated
These values describe the current environment. If crossOriginIsolated is false, continue checking the final COOP and COEP headers, embedding restrictions, and permissions policy instead of changing only static-asset headers. Even with isolation active, individual APIs have their own requirements and browser support limitations.
COOP: same-origin can change relationships between cross-origin popups and their opener. Test third-party sign-in, payment flows, and window-based messaging explicitly. Restored homepage images do not establish compatibility for these workflows.[3]
Embedded frames and workers can have additional requirements. Adding two headers to the top-level document does not prove that the whole application is compatible. Start with controlled routes and a test environment rather than a site-wide rollout.
Roll out from an asset inventory and keep a tested rollback
Back up application, web server, and CDN rules. List critical images, scripts, fonts, workers, and third-party embeds, including their request mode, origin, credential needs, and intended permission mechanism.
During a limited rollout, verify that:
Resources load in fresh sessions and existing tabs without the corresponding blocking errors.
Isolation matches the application’s requirement and the necessary APIs actually work.
Authentication, payment, popups, and embedded components remain functional without exposing sensitive resources.
Origin and edge responses agree, and browser or Service Worker caches are not supplying an older document.
If invalidation is necessary, target affected objects and verify that both headers and bodies have updated. A broad purge can increase origin load and does not clear client-side caches.
If the change fails, restore the previous tested configuration. Determine whether isolation-dependent functionality also needs rollback or a clear degraded-mode message. Removing COEP may make those features unavailable, so restored images alone do not prove that rollback is complete.
Document which policy constrained each failed resource, which request mode applied, and why the repaired permission is appropriate. That inventory is more useful than adding security headers to every response without understanding their effect.
References
References checked on October 23, 2026 for the corresponding Chinese article. Adjust examples to the site’s purpose, supported browsers, and CDN rules.
