Cross-Origin-Resource-Policy (CORP) is a response header that tells the browser to block no-cors requests for a resource from other origins or sites. CORS does the reverse: it grants other origins permission to read a response. CORP restricts embedding, CORS relaxes reading.
The three values
| Value | Who may load the resource |
|---|---|
same-origin | Only the same origin: scheme, host and port all match |
same-site | Any page on the same site, which is looser than an origin |
cross-origin | Any origin, which you need when a page uses COEP require-corp |
MDN warns that same-site is less secure than same-origin, because the same-site check works on the registrable domain, so sibling subdomains are included.
What CORP actually blocks
CORP only applies to no-cors requests, the kind a plain image or script tag makes by default. A subtle point from MDN: the request is not prevented. The browser still fetches the resource, then strips the response body so the embedding page cannot use the result. That matters because CORP was designed as a defence against speculative side channel attacks such as Spectre, where the danger is a page getting the bytes into its own process.
CORP is described as an additional layer on top of the same-origin policy, not a replacement. It also helps with cross-site script inclusion, where another site tries to load your authenticated JSON or script response as its own resource.
CORS and CORP side by side
| Question | CORS | CORP |
|---|---|---|
| Who sets it | Resource server | Resource server |
| Default if unset | No cross-origin reads from script | No restriction on no-cors embedding |
| Purpose | Allow reads | Block embedding |
| Covers | Requests in cors mode | Requests in no-cors mode |
When to add it
- Sensitive, user specific resources such as avatars, invoices or JSON that returns private data: send
same-origin. - Public assets you want others to embed, like a logo CDN: send
cross-originon purpose, so isolated pages using COEP can load them. - Assets shared between subdomains you control:
same-siteis acceptable if you trust every subdomain.
If any of your pages rely on COEP, the assets they embed must carry CORP or be fetched with CORS, so plan the two headers together. The earlier posts on COOP and COEP and on require-corp versus credentialless cover that side.
A caveat before you deploy
MDN's guide notes a Chrome bug at the time of writing in which setting CORP can break PDF rendering, so visitors cannot read past the first page of some PDFs. Test your PDF downloads before applying the header site wide, and check whether the issue still applies in the browsers you support.
Quick check
Does CORP stop someone from calling my API with curl?
No. CORP is enforced by browsers. A direct request from any other client is unaffected, so keep real authentication and authorisation in place.
Does CORP replace CORS headers?
No. They solve opposite problems. Many resources need CORS to allow reads and CORP to control embedding.
Safeguard's scans cover your dependencies and SBOM rather than HTTP headers, so pair a header review with a dependency check on the packages your front end ships. The free scan is at gold.safeguard.sh/scan.
Sources
- Cross-Origin-Resource-Policy header, MDN
- Cross-Origin Resource Policy guide, MDN
- Cross-Origin-Embedder-Policy header, MDN
Last reviewed: 19 October 2026.
