Cybersecurity glossary
What is Cross-Origin Resource Policy (CORP)?
Learn what Cross-Origin Resource Policy (CORP) is, how Cross-Origin-Resource-Policy values control cross-origin loading, why it pairs with COEP, and how to opt resources into isolation safely.
Definition
Cross-Origin Resource Policy (CORP) is an HTTP response header that declares whether a resource may be loaded by documents from other origins, helping browsers block unintended cross-origin inclusion and enabling opt-in for pages using Cross-Origin Embedder Policy.
Why CORP matters
Browsers load images, scripts, fonts, and workers from many origins on a single page. Without an explicit policy, a resource may be included by any site that knows its URL. That permissive default complicates isolation and can widen cross-origin gadget surfaces.
Cross-Origin Resource Policy (CORP) lets resource owners declare who may load a response. Tight values reduce drive-by inclusion. Permissive values, combined with CORS where appropriate, let cross-origin isolated pages embed only resources that intentionally opt in.
How CORP works
The server sends Cross-Origin-Resource-Policy on a response. When another document requests that resource, the browser compares the requester's origin against the policy before allowing the load.
Resource emits CORP
The origin attaches Cross-Origin-Resource-Policy with a value such as same-origin or cross-origin.
Cross-origin page requests it
A document from another origin attempts to load the resource as a script, image, worker, or other subresource.
Browser evaluates policy
The user agent checks CORP together with COEP, CORS, and same-origin rules for that request type.
Load allowed or blocked
Compatible policies permit inclusion. Incompatible combinations fail the load before sensitive data is exposed.
Isolation stack completes
With COOP and COEP on the document, CORP opt-in on subresources supports a cross-origin isolated context.
Common CORP values
same-origin
Only same-origin documents may load the resource. Strongest default for sensitive static assets.
same-site
Allows inclusion from same-site origins (scheme + registrable domain). Useful for multi-subdomain estates.
cross-origin
Explicitly permits cross-origin loading. Often paired with CORS when COEP requires opt-in.
No header
Legacy permissive behavior for many resource types. Relying on absence is weaker than an explicit policy.
CORP by resource type
| Resource | Typical CORP | Why |
|---|---|---|
| Same-origin JS bundles | same-origin | Prevents other sites from hotlinking executable code |
| CDN fonts and images for one site | same-site or same-origin | Blocks unrelated origins while allowing owned subdomains |
| Third-party widget script | cross-origin + CORS as needed | Intentional embed across customer sites under COEP |
| Authenticated API JSON | Usually omit CORP; use CORS | CORP targets inclusion, not read access to API bodies |
| SharedArrayBuffer worker file | cross-origin with COEP page | Required opt-in path for isolated pages loading cross-origin workers |
Deployment checklist
- Inventory subresources loaded by isolated pages and mark which need CORP cross-origin opt-in.
- Default sensitive static assets to same-origin unless a documented cross-site need exists.
- Do not confuse CORP with CORS; configure each for its distinct browser check.
- Set CORP at the CDN or origin for cacheable assets, not only on HTML documents.
- Test COEP require-corp pages in staging; missing CORP breaks images, fonts, and workers.
- Avoid blanket cross-origin on APIs that should never be embedded as subresources.
- Pair CORP decisions with Subresource Integrity where third-party scripts are unavoidable.
- Monitor console CORP violations after tightening policies on production traffic.
Limits and pitfalls
CORP does not replace authentication or CORS for API reads. A resource with cross-origin CORP can still be fetched with credentialed XHR when CORS allows it; CORP only governs certain inclusion contexts.
Another pitfall is applying same-origin to assets that legitimate partner sites must embed, then "fixing" the break by weakening COEP instead of issuing targeted cross-origin CORP on those files. Plan opt-in paths before enabling isolation.
The practical takeaway
Cross-Origin Resource Policy (CORP) tells browsers which origins may load a resource as a subresource. It is a building block for cross-origin isolation and a direct control against unintended cross-site inclusion.
Set CORP deliberately per asset class, coordinate it with COEP and CORS, and treat missing policies on sensitive static files as an open inclusion surface rather than harmless legacy behavior.
Related security terms
Cross-Origin Embedder Policy (COEP)
Embedder policy that often requires CORP or CORS opt-in on cross-origin subresources.
Cross-Origin Resource Sharing (CORS)
A separate mechanism for cross-origin reads; CORP governs inclusion, not response visibility.
Cross-Origin Opener Policy (COOP)
Companion isolation header focused on window relationships rather than resource loading.
Same-Origin Policy (SOP)
The baseline browser boundary that CORP strengthens for resource inclusion.
Frequently asked questions
What is CORP in simple terms?
CORP is a header on a file or API response that says whether other websites are allowed to load it. A strict value such as same-origin blocks cross-origin pages from embedding that resource unless another opt-in mechanism applies.
How is CORP different from CORS?
CORS controls whether JavaScript on one origin may read the response body from another origin. CORP controls whether a resource may be loaded at all by a cross-origin document, including as images, scripts, or workers.
What does Cross-Origin-Resource-Policy: same-origin do?
It allows only same-origin documents to load the resource. Cross-origin pages are blocked from including it unless COEP and CORS together provide an explicit exception path.
Why does COEP mention CORP?
COEP with require-corp blocks cross-origin embeds unless each resource opts in through CORP or CORS. CORP is how static assets and APIs declare they are safe to load in an isolated page.
Does CORP protect against Spectre?
CORP is part of the isolation stack. It reduces cross-origin resource inclusion that could widen attack surface, but it is not a standalone Spectre fix. Full isolation requires COOP, COEP, and careful resource opt-in.
Should APIs send CORP on JSON responses?
Usually not by default. CORP is most valuable on subresources meant to be embedded. Misapplied CORP on APIs can break legitimate cross-origin fetches that rely on CORS without improving security.
References
Explore authoritative guidance and frameworks related to cross-origin resource policy (corp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.