How to Configure Strict Cross-Origin Resource Policy (CORP) in Google Chrome

Modern browser security models permit web pages to load subresources such as images, media files, and scripts from cross-origin origins by default. However, side-channel attacks such as Spectre demonstrate that speculative execution mechanisms in CPUs can read sensitive data loaded into the same renderer process. Cross-Origin Resource Policy (CORP) addresses this structural vulnerability by allowing servers to explicitly declare who can embed their static assets. In Google Chrome, enforcing strict CORP headers prevents unauthorised origins from reading or embedding sensitive media and API responses.

Understanding CORP Directives and Process Boundaries

The Cross-Origin-Resource-Policy response header functions at the resource level, telling Chrome whether a resource should be blocked from entering an external execution context. It provides three explicit values:

• same-origin: The most restrictive setting. Only requests originating from the exact same protocol, domain, and port can load the asset. Any external document attempting to embed the file via an <img>, <audio>, or <script> tag triggers a network error in Chrome.
• same-site: Allows requests originating from the same registrable domain and eTLD+1 (for instance, allowing subdomains like media.example.com to load assets on app.example.com).
• cross-origin: Explicitly signals that any origin can embed the resource. This is required when serving public content that must be embedded on pages employing Cross-Origin Embedder Policy (COEP).

Configuring Web Server Headers for CORP Enforcement

To defend your confidential files, authenticate static endpoints, and safeguard API responses, configure your server to transmit the header with every eligible response:

# Nginx configuration for static assets
location /secure-assets/ {
    add_header Cross-Origin-Resource-Policy "same-origin" always;
    add_header X-Content-Type-Options "nosniff" always;
}

# Apache HTTP Server (.htaccess / virtual host)
<FilesMatch ".(png|jpe?g|pdf|json)$">
    Header always set Cross-Origin-Resource-Policy "same-origin"
    Header always set X-Content-Type-Options "nosniff"
</FilesMatch>

Auditing CORP Violations in Chrome DevTools

When an unauthorised origin attempts to load a CORP-protected file, Google Chrome blocks the response body before the rendering engine processes it:

1. Open Google Chrome and navigate to the web application.
2. Press Ctrl + Shift + I (or Option + Command + I on macOS) to launch Chrome DevTools.
3. Select the Network tab and click on the blocked request.
4. Navigate to the Headers panel and verify that Cross-Origin-Resource-Policy: same-origin is present under Response Headers.
5. Check the Console panel for explicit blocking notifications:

   GET https://api.example.com/data.json net::ERR_BLOCKED_BY_RESPONSE.NotSameOrigin 200 (OK)

6. Inspect the Issues tab in DevTools, which highlights resources blocked due to CORP and explains which origin failed the security evaluation.

Integrating CORP with Cross-Origin Isolation

When authoring modern high-performance web applications that utilise SharedArrayBuffer or audio worklets, Chrome requires a cross-origin isolated environment enabled via COOP and COEP. If an isolated page embeds third-party media or scripts, those external dependencies must explicitly serve Cross-Origin-Resource-Policy: cross-origin; otherwise, Chrome blocks them completely. Configuring granular CORP headers ensures that internal enterprise data remains locked to same-origin while public marketing assets remain embeddable across federated environments.