Cross-origin isolation often gets reduced to a checklist of response headers. A team adds Cross-Origin-Resource-Policy to one service, Cross-Origin-Embedder-Policy to another and assumes the pair closes the boundary. The two controls act at different layers. One protects a resource from being embedded without permission; the other makes a document require explicit permission for cross-origin subresources.
The Fetch Standard defines Cross-Origin-Resource-Policy values including same-origin, same-site and cross-origin. It is evaluated when a response is delivered in a cross-origin context that does not use CORS. A response marked same-origin should not be exposed to another origin through a no-cors image, script or similar request. same-site relaxes the rule to the registrable-site boundary and is not equivalent to the same origin.
Cross-Origin-Embedder-Policy belongs to the embedding document. A COEP value compatible with cross-origin isolation, such as require-corp, makes the document reject cross-origin resources that do not opt in through CORP or CORS. credentialless is another COEP mode. The HTML Standard defines how these values interact with cross-origin isolation.
This distinction affects deployment order. Adding CORP to an API may protect responses without changing whether the page becomes cross-origin isolated. Adding COEP to the page can immediately break images, fonts, scripts and frames that previously loaded without CORS. The page needs a resource inventory and a staged report-only or telemetry period before enforcement.
CORP is not authentication. A resource can allow cross-origin and still require cookies, tokens or network-level controls. CORP does not stop a server-side request, a browser extension or a client that ignores browser policy. It limits browser exposure for no-cors response types. COEP does not make a request trustworthy just because it opts in; the destination still needs authorization and content validation.
The site boundary is a common source of mistakes. Two hosts under the same registrable domain may be same-site while remaining different origins. A same-site CORP policy therefore permits a broader set of embedders than same-origin. A compromised sibling host can matter when the threat model treats the whole site as one trust domain.
Credential behavior also needs review. A cross-origin resource that uses CORS with credentials requires an explicit origin policy. CORP and COEP do not replace that policy. Conversely, COEP can cause a resource loaded without credentials to fail when the resource owner has not supplied the needed headers. Test both anonymous and authenticated sessions.
Use a resource matrix that records origin, fetch mode, credentials, CORP policy and COEP requirement. Capture console errors and blocked requests in staging. Then remove unused cross-origin dependencies or move them behind an approved gateway before enforcing isolation.
The final check is behavioral. From a hostile origin, attempt to load sensitive resources through the relevant no-cors elements. From the protected document, verify that every intended subresource loads and every unintended one fails. The browser should enforce the intended relationship, while server-side authorization continues to protect the data even when headers are absent.