Cross-Origin-Resource-Policy: who may embed this response
Cross-Origin-Resource-Policy is set by the resource rather than the page, and tells the browser which sites may embed that response at all, independently of CORS.
At a glance
- Direction
- Response only. It is set by the server that owns the resource.
- Defined in
- The Fetch standard (WHATWG)
- When absent
- No protection, except inside a document sending Cross-Origin-Embedder-Policy: require-corp, where the resource is blocked.
- Values
- same-origin, same-site, cross-origin
- Applies to
- no-cors embedding such as img, script, audio and video, not to fetch with CORS
- Defends against
- Side channel attacks that infer content by embedding a response cross-origin
- In the headers checker
- Shown in the raw response header table. It is not one of the graded headers.
In detail
CORS answers whether a page may read a response. This header answers a different question: whether the browser should fetch the resource for another site at all. A private image endpoint that sends same-origin cannot be embedded by an attacker's page even as an opaque image, which removes the timing and size measurements that make speculative side channel attacks practical.
The same-site value is looser than same-origin and matches the registrable domain, so app.example.com may embed a resource from static.example.com, while a completely different domain may not. Scheme matters too: an https resource marked same-site refuses an http page on the same domain, which is one of the more confusing rejections to debug.
The cross-origin value means anyone. That sounds like the absence of the header, and for a normal page it is, but it is exactly what a public asset host must send once its consumers start using Cross-Origin-Embedder-Policy: require-corp. Under that policy an absent resource policy header is a blocked resource, so public asset hosts have to opt in explicitly.
Because the header lives on the resource, you cannot fix a blocked third party asset from your own configuration. Either the operator adds the header, or you load the resource with CORS and a crossorigin attribute so it passes the check the other way, or you proxy it through your own origin.
Examples
Cross-Origin-Resource-Policy: same-originCross-Origin-Resource-Policy: cross-originRequired for the asset to remain usable inside documents that set Cross-Origin-Embedder-Policy: require-corp.
HTTP/1.1 200 OK
Content-Type: image/png
Cross-Origin-Resource-Policy: same-siteThings that catch people out
- The header does nothing about requests made with CORS. A fetch that already passes an Access-Control-Allow-Origin check is not blocked by it.
- same-site includes subdomains but not different schemes, so mixed http and https during a migration produces rejections that look like a CORS problem and are not.
- You cannot add this header to somebody else's asset. If a third party resource breaks under require-corp, the fix is theirs, or yours by proxying.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Cross-Origin-Embedder-Policy: require-corp and credentialless
What require-corp demands from every subresource, how credentialless relaxes it, and why enabling COEP is what breaks third party images and embeds.
Cross-Origin-Opener-Policy: isolating your browsing context
What COOP severs between your page and the windows it opens, how same-origin differs from same-origin-allow-popups, and its part in cross-origin isolation.
Access-Control-Allow-Origin: who may read this response
How the allow origin header is matched, why a wildcard fails with credentials, why it takes only one origin, and why Vary: Origin is mandatory when you echo.
Timing-Allow-Origin: exposing detailed resource timings
Why cross-origin resources show zeroed timings, what Timing-Allow-Origin unlocks in the Resource Timing API, and how it differs from a CORS allow header.
Clear-Site-Data: wiping browser state on logout
How Clear-Site-Data clears cookies, storage and caches for your origin, which directives are safe on a logout response, and where support is uneven.
Reporting-Endpoints: where browser reports are sent
How Reporting-Endpoints names collectors for CSP violations and deprecation warnings, how it differs from the older Report-To header, and what arrives.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body