Cross-Origin-Resource-Policy (CORP) Explained
CORP tells browsers which cross-origin contexts may load a resource. Learn same-origin, same-site, and cross-origin values and how CORP supports COEP and COOP isolation.
Cross-Origin-Resource-Policy (CORP) is a response header on a resource (script, image, document, font) that declares which embedder origins may load it. It is the counterpart many CDNs and apps need when a page enables COEP require-corp.
Read this alongside COOP. PatchPings ships COOP without requiring COEP/CORP on the marketing site; use CORP when your own isolation goals demand it.
CORP values
- `same-origin` — only same-origin pages may load the resource.
- `same-site` — same registrable domain (scheme-inclusive same-site rules) may load it.
- `cross-origin` — any origin may load it (explicit opt-in for embedding).
Cross-Origin-Resource-Policy: same-origin Cross-Origin-Resource-Policy: cross-origin
Where to set CORP
Put CORP on the resource responses, not only on HTML documents. Static assets on your CDN often need cross-origin if other sites or a COEP page must embed them. Sensitive API responses more often stay same-origin.
CORS governs credentialed reads via fetch/XHR. CORP governs whether the resource may be loaded as a no-CORS embed. You may need both.
Isolation stack at a glance
- COOP — isolates browsing context groups /
window.opener. - COEP — requires embedded resources to opt in.
- CORP — is how resources opt in (or stay private).
Verification
- 1Decide per asset class: private (
same-origin) vs embeddable (cross-origin). - 2Deploy headers at the edge that serves those bytes.
- 3Load a COEP test page and watch for blocked resources in DevTools.
- 4Grade the broader header set with a security headers check or security headers checker.
CORP makes embedding intent explicit. Use it to protect sensitive responses, to unlock COEP on apps that need isolation, and to keep the COOP → COEP → CORP story coherent without forcing every brochure page into full cross-origin isolation.
