A browser prevents one website's JavaScript from freely reading another site's private data. Yet the web also allows many resources to be embedded across origins. Images, scripts, styles, audio, video, and other files can travel through request modes that do not give the embedding page normal access to the response body.
Cross-Origin Resource Policy, or CORP, lets the resource owner draw a firmer boundary. A response header tells the browser whether a resource may be loaded by the same origin, the same site, or any origin.
How Cross-Origin Resource Policy blocks loads
CORP is expressed through the Cross-Origin-Resource-Policy response header. It mainly applies to cross-origin requests made in no-cors mode, including common loads initiated by elements such as img and script.
The request can still reach the server. The important enforcement happens when the response returns. If the policy does not allow the requesting context, the browser blocks the response body from being delivered to the destination.
The Fetch Standard defines the browser's CORP check. MDN's Cross-Origin Resource Policy reference summarizes the header values and practical behavior.
Three values express different boundaries
same-origin is the narrowest common value. The resource may be used only when the requester has the same scheme, host, and port. This fits private application responses and assets that should never leave one origin.
same-site allows origins that belong to the same site. It can support an application at one subdomain and a static asset service at another, but teams must remember that a compromised sibling subdomain may fall inside the allowed boundary.
cross-origin explicitly allows cross-origin embedding. Public CDNs, fonts, images, and widgets may need this declaration, especially when embedded by a document enforcing Cross-Origin Embedder Policy.
Our guide to the same-origin policy explains why origin and site are different security concepts. Choosing between them should be an architectural decision, not a convenient guess.
CORP is not CORS
Cross-Origin Resource Sharing, or CORS, controls whether browser APIs such as fetch() may make cross-origin requests and expose responses to JavaScript. A server uses headers such as Access-Control-Allow-Origin to name acceptable origins.
CORP protects a resource from certain no-cors cross-origin loads. It does not grant JavaScript permission to read the response. Setting Cross-Origin-Resource-Policy: cross-origin therefore does not turn a private API into a public CORS API.
The inverse is also important. A resource that supports an intentional CORS workflow should be tested before a restrictive CORP header is added. Security headers interact through request modes and embedding rules, and a policy that looks sensible in isolation can still break a real client.
Why blocked reading is not the whole problem
The same-origin policy stops a hostile page from directly reading many cross-origin responses, but embedding can still reveal information. Load success, timing, dimensions, error behavior, cache state, and other side effects may expose facts about a user's account or activity.
These techniques belong to a broader category called cross-site leaks, or XS-Leaks. Some attacks also exploit speculative execution behavior to infer data that should remain outside the attacker's context.
CORP reduces this surface by preventing protected response bodies from entering contexts that did not receive permission. It does not eliminate every timing or state leak, but it gives resource owners a direct way to opt out of permissive embedding.
Private images are a useful example
Imagine an authenticated endpoint that returns a user's profile image. An unrelated site may not be able to read the pixels through JavaScript, but it might still embed the URL in an image element and observe whether loading succeeds or how the image behaves.
A same-origin CORP header tells supporting browsers that the response must not be supplied to that cross-origin image load. The correct policy is still only one layer: the server must authenticate the request, authorize the user, and avoid predictable resource URLs where they create exposure.
CORP should reinforce access control rather than stand in for it. A non-browser client can ignore the header, and the server has already received the request before the browser blocks the response.
How CORP works with COEP and COOP
Cross-Origin Embedder Policy, or COEP, lets a document require embedded cross-origin resources to opt in through CORS or an appropriate CORP value. This helps the browser build a context containing only resources that consent to cross-origin use.
Combined with Cross-Origin-Opener-Policy: same-origin, a compatible COEP policy can produce a cross-origin-isolated page. Our article on Cross-Origin Opener Policy covers the top-level window boundary and the popup compatibility issues it can introduce.
CORP speaks for the resource. COEP speaks for the document doing the embedding. COOP controls the document's relationship with other top-level windows. Similar names hide three distinct jobs.
Deploy per resource class
A single site may serve private JSON, public logos, authenticated images, shared fonts, scripts, and downloadable documents. Applying one CORP value to every response can break public assets or leave sensitive files too open.
Group routes by intended audience. Private application responses often fit same-origin. Shared subdomain assets may require same-site. Deliberately public resources can use cross-origin when broad embedding is part of the product.
Use browser developer tools and server logs to find blocked resources. Test redirects and CDN responses too, because the final response needs the correct header. Fetch Metadata can complement CORP by helping the server reject suspicious request contexts before application logic processes them.
A practical CORP checklist
- Inventory which resources are private, same-site shared, or intentionally public.
- Start with sensitive authenticated responses that should never be embedded elsewhere.
- Apply the header at the final response, including CDN and redirect destinations.
- Test images, fonts, scripts, downloads, media, and worker-related resources.
- Distinguish CORS API access from no-CORS embedding requirements.
- Monitor blocked loads before expanding the policy across an entire domain.
Cross-Origin Resource Policy gives a file a clear opinion about where it belongs. The browser may already restrict what another site can read, but CORP goes further by refusing to deliver protected responses into disallowed contexts. That smaller exposure is worth making explicit.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.