Cross-Origin-Resource-Policy
Send `Cross-Origin-Resource-Policy: same-origin` on responses only your own site should load, and `cross-origin` on assets meant to be public.
Send this header. There is no meaningful downside for a typical site.
What it does
CORS governs whether a script may *read* a cross-origin response. CORP governs whether the browser will load it into another origin at all — including in ways that never expose the bytes to script, such as an `<img>` tag or a `<script>` include. That distinction is what makes it useful against speculative-execution side channels, where the attack is having your data in the attacker's process rather than reading it through an API.
The right value is a property of the resource, not the site. An API response or a user-specific document should say `same-origin`: no other site has a legitimate reason to embed it. A public logo, font or CDN asset should say `cross-origin`, and must, if it is to remain usable by pages that have enabled COEP.
`same-site` sits between them and is the value to use for a separate asset hostname you control — `static.example.com` serving `app.example.com`. Note that it is a weaker boundary than it looks: any subdomain of the registrable domain qualifies, including one a different team or a compromised vendor controls.
What to send
Cross-Origin-Resource-Policy: same-originDefault to `same-origin` for application responses, then override to `cross-origin` on the specific paths meant to be embedded elsewhere. Getting it backwards is the common failure: a CDN that sends `same-origin` breaks every consumer, and an API that sends `cross-origin` has opted into exactly what the header exists to prevent.
Directives and values
Only pages from the identical scheme, host and port may load this resource. The correct default for API responses and anything user-specific.
Any host under the same registrable domain may load it. Useful for a separate static hostname, but note that it trusts every subdomain.
Anyone may load it. Required on public assets — and required for those assets to work in pages that have enabled COEP `require-corp`.
Common mistakes
- Sending same-origin from a CDN or asset host. Every page that embeds the asset stops rendering it, usually silently. Assets intended for other origins need `cross-origin`, and increasingly must send it to work at all in COEP-enabled pages.
- Treating it as a replacement for CORS. They answer different questions. CORP decides whether the resource may be loaded into another origin; CORS decides whether script there may read the response. An API generally needs both configured, and they are not substitutes.
- Relying on same-site as a security boundary. It admits every subdomain of the registrable domain. If any subdomain is delegated to a vendor, run by another team, or vulnerable to takeover, it is inside the boundary.
- Setting it globally without auditing embeds. A blanket `same-origin` breaks legitimate embedding — RSS images, oEmbed thumbnails, partner integrations, OG images fetched by social platforms. Decide per path.
Browser support
Supported in all current major browsers. It is also the mechanism COEP `require-corp` checks, so its practical importance has grown: an asset without CORP is invisible to any cross-origin-isolated page.
Frequently asked questions
What is the difference between CORP and CORS?
CORS decides whether script on another origin may read a response. CORP decides whether the browser will load the resource into another origin at all, including through tags such as `<img>` and `<script>` that never expose the bytes to script. They solve different problems and are usually configured together.
What CORP value should a CDN send?
`cross-origin`. Assets meant to be embedded by other sites must say so, and under COEP `require-corp` a resource without that header is blocked outright — so an asset host sending `same-origin` breaks every consumer.
Is same-site a safe CORP value?
It is reasonable for a static hostname you control alongside your application, but it trusts every host under the same registrable domain. If any subdomain is vendor-operated, delegated or at risk of takeover, it sits inside that boundary — prefer `same-origin` for anything sensitive.
Does CORP protect API endpoints?
It prevents other origins embedding the response, which removes a side-channel exposure that CORS alone does not address. It is not an authorisation mechanism — an endpoint returning sensitive data still needs authentication and correct CORS configuration.
The free Security Headers Checker reads Cross-Origin-Resource-Policy from a live response and grades it alongside every other header on this reference — no account needed.
For the longer treatment, read Advanced HTTP Security Headers: A Deep Dive in the Learning Center.
Related headers
Requires every cross-origin resource to opt in. The second half of cross-origin isolation, and the expensive half.
Severs the link between your page and windows that opened it. Required for cross-origin isolation — and it breaks popup flows.
One value, one line, no downside worth mentioning. Stops browsers second-guessing your Content-Type.