Cross-Origin Resource Policy: Isolating Web Assets

The Cross-Origin Resource Policy (CORP) HTTP header provides web developers with a robust defense mechanism to prevent sensitive assets from being loaded by unauthorized third-party websites. By explicitly defining which origins can read and embed specific resources, CORP mitigates the risk of cross-origin data leaks, speculative execution attacks such as Spectre, and unauthorized resource inclusion. This article outlines the mechanics of the CORP header, its available directives, and how it establishes asset isolation within modern web architectures.

The Vulnerability CORP Solves

Traditionally, the web platform operates under an open-by-default model for resource embedding. While the Same-Origin Policy (SOP) prevents a script on one origin from reading the raw contents of a response from another, it historically allowed elements like <img>, <video>, <audio>, and <script> to fetch and render cross-origin resources.

This model introduced severe security liabilities. Malicious sites could hotlink sensitive resources or exploit speculative execution side-channel attacks (like Spectre) to read memory containing sensitive cross-origin data that had been loaded into the browser's execution context. Unlike Cross-Origin Resource Sharing (CORS), which dictates whether JavaScript can access a response, CORP instructs the browser whether the resource can be loaded or embedded by external origins at all.

CORP Directives

The Cross-Origin-Resource-Policy response header supports three distinct values, granting granular control over resource distribution:

  • same-origin: Only requests originating from the exact same scheme, host, and port can read or embed the resource. This is the most restrictive and secure setting, recommended for private user data, authenticated endpoints, and sensitive assets.
  • same-site: Allows the resource to be embedded by the same origin as well as subdomains under the same registrable domain (e.g., app.example.com and static.example.com).
  • cross-origin: Explicitly allows any origin to embed the resource. This is typically applied to public assets, such as open-source libraries or publicly accessible marketing images, especially in environments enforcing strict isolation policies.

Enabling Cross-Origin Isolation

CORP plays a foundational role in enabling "Cross-Origin Isolation" via the Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP). When an application enforces Cross-Origin-Embedder-Policy: require-corp, the browser will refuse to load any cross-origin resource unless the resource explicitly opts in using either a valid CORS header or a Cross-Origin-Resource-Policy: cross-origin header.

Enabling full cross-origin isolation unlocks powerful browser features, such as SharedArrayBuffer and high-resolution performance timers (performance.now()), while ensuring that no ambient third-party data is leaked into process-shared memory spaces.

Best Practices for Implementation

To properly isolate sensitive web assets using CORP:

  1. Default to Restriction: Configure web servers and CDNs to serve Cross-Origin-Resource-Policy: same-origin by default on all authenticated endpoints, user-specific data formats (JSON, XML), and private media files.
  2. Audit Static CDNs: For static, shared resources (such as fonts and public scripts), serve Cross-Origin-Resource-Policy: cross-origin to prevent breakage on consumer sites that enforce COEP.
  3. Combine with Fetch Metadata: Use CORP in conjunction with Sec-Fetch-* request headers to establish multi-layered defense-in-depth against Cross-Site Request Forgery (CSRF) and cross-site resource inclusion attacks.