Security and privacy

Cross-Origin-Resource-Policy HTTP Header

Declares which origins may request a resource in certain cross-origin contexts.

Applicability

This field applies to HTTP responses.

Syntax

Cross-Origin-Resource-Policy: same-origin | same-site | cross-origin

Examples

Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Resource-Policy: same-site

Common use cases

  • Keep private application resources from being embedded by unrelated origins.
  • Explicitly allow a public asset to participate in a COEP-protected application.

Common mistakes

  • Confusing same-site with same-origin and overlooking sibling subdomains within one registrable site.
  • Applying same-origin to CDN-hosted assets without testing the consuming application's origin.

Security considerations

CORP can reduce cross-origin data exposure through no-CORS embedding, but it does not authorize API reads or sanitize public resource contents.

Use the Security Headers Checker to evaluate supported browser-facing protections on a public website.

Detailed guidance

Meaning and behavior

Cross-Origin-Resource-Policy, or CORP, is sent by a resource to constrain no-CORS cross-origin use of its response. same-origin permits use only when the requesting origin matches, including scheme, host, and port. same-site permits origins belonging to the same schemeful site, a broader boundary that can include sibling subdomains. cross-origin explicitly permits cross-origin use and is useful when a public resource must load inside a document protected by Cross-Origin-Embedder-Policy.

CORP differs from CORS. CORS determines whether a browser exposes a response to script in a CORS request. CORP can block a no-CORS response body from being delivered for embedding even though the network request was made. It also differs from COEP: COEP is declared by the embedding document, while CORP is an opt-in statement from the resource. Choosing the wrong boundary can break images, fonts, media, and scripts served from a separate asset origin.

Implementation notes

Classify each resource by intended consumers. Use same-origin for private resources with no cross-origin embedding requirement, and consider same-site only after reviewing the trustworthiness of every sibling origin. Use cross-origin for genuinely public assets that need explicit compatibility, not as a blanket default. Verify asset hosts, CDN aliases, redirects, cached variants, and error responses. Test from both an allowed document and an unrelated origin. When COEP is involved, confirm that the request mode and CORS headers also align; CORP alone does not guarantee every cross-origin loading path succeeds.

Sources