Strengthening Web Security with the Cross-Origin Resource Policy (CORP) HTTP Header

As an industry-leading web security specialist with over two decades of experience, I've worked extensively with enterprises seeking to protect their applications from cross-origin threats. One powerful yet often overlooked mechanism is the Cross-Origin Resource Policy (CORP) HTTP header. This header can thwart hotlinking, cross-site script inclusion (XSSI), and speculative side-channel attacks such as Spectre—ultimately enhancing a website's defensive posture. Below, we'll explore how CORP functions, the risks of not using it, and practical steps for configuring it in Apache, Nginx, and IIS.

What Is the Cross-Origin Resource Policy?

Cross-Origin Resource Policy is a security measure communicated via the Cross-Origin-Resource-Policy response header. It offers websites and applications the ability to control which external origins can embed certain resources—especially images, scripts, and other media. Although the same-origin policy blocks many cross-origin requests (particularly JavaScript-based fetch calls), it doesn't prevent embedded resources from being accessed cross-origin by default. CORP helps fill that gap.

Key Insight: CORP specifically focuses on resources embedded without CORS checks, such as images, scripts, and other media loaded through HTML elements like <img>, <script>, or <video>.

Why CORP Matters

Speculative Side-Channel Attacks

Vulnerabilities like Meltdown and Spectre showed how malicious parties could extract sensitive information by exploiting the browser's speculative execution. CORP adds an extra line of defense, preventing loaded resources from leaking data to a hostile website.

Cross-Site Script Inclusion (XSSI)

Attackers can sometimes load your scripts in their own pages to glean user data or internal application details. CORP can instruct browsers to block such attempts.

Hotlinking Prevention

CORP can help deter unauthorized embedding of your site's images or other media, minimizing bandwidth theft and plagiarism.

How the Cross-Origin Resource Policy Works

Key Header Values

The Cross-Origin-Resource-Policy header accepts three possible values, each specifying different levels of restrictiveness:

same-origin Most Restrictive

Only resources loaded from the exact same scheme, host, and port are allowed.

Example: If set on https://example.com, resources can only be embedded within pages from the same domain, using the same protocol and port.

same-site Moderately Restrictive

Resources may be loaded from the same site, regardless of subdomain or port number.

Example: If set on https://api.example.com, resources can be embedded by pages from https://example.com or https://shop.example.com.

cross-origin Least Restrictive

Any origin can embed the resource. This is the least restrictive policy and may be needed if you want your assets to be widely embeddable (e.g., for public-facing APIs, CDNs, or widgets).

Example: If set on https://cdn.example.com/image.jpg, any website can embed this image.

When CORP Applies

No-CORS Requests: The header specifically governs resources fetched in no-cors mode. Common examples include embedded content such as <img> and <script> elements that do not use the crossorigin attribute.
Behavior in Modern Browsers: Modern browsers (Chrome, Firefox, Safari) support CORP, but keep an eye on Chrome's PDF rendering bug, which sometimes prevents users from scrolling beyond the first page if the resource is served with CORP.

CORP vs. CORS

CORS (Cross-Origin Resource Sharing)	CORP (Cross-Origin Resource Policy)
Loosens restrictions by allowing cross-origin requests if explicitly permitted.	Tightens restrictions for embedded resources that would typically bypass same-origin policy protections.
Uses `Access-Control-Allow-Origin` header to grant access.	Uses `Cross-Origin-Resource-Policy` header to restrict access.
Primarily affects JavaScript API fetch/XHR requests.	Primarily affects embedded resources (images, scripts, etc.).
Opens communication channels that would otherwise be blocked.	Closes channels that would otherwise be open by default.

While CORS focuses on enabling controlled cross-origin access (usually via Access-Control-Allow-Origin), CORP restricts or denies embedding of resources unless certain conditions are met. Both can coexist but serve different purposes in managing cross-origin requests.

Potential Risks of Not Using Cross-Origin Resource Policy

Security Risks

Omitting CORP can leave your website exposed to:

Cross-Site Script Inclusion (XSSI): Attackers may embed your JavaScript resources on their domain to extract private data.
Resource Hotlinking: Other sites can load your images or media content, potentially inflating bandwidth costs and enabling unauthorized content distribution.
Side-Channel Data Leaks: Spectre-like attacks can glean confidential data if malicious websites manage to load your site's resources in a no-cors context.

Implementing Cross-Origin Resource Policy in Different Servers

Below are step-by-step instructions for setting up the Cross-Origin-Resource-Policy header on Apache, Nginx, and IIS. Choose the header value that best meets your security needs (same-origin, same-site, or cross-origin).

Apache

Nginx

IIS

1. Enable the Headers Module (if not already enabled):

a2enmod headers

2. Set the CORP Header:

In your server configuration or .htaccess file, add:

<IfModule mod_headers.c>
    Header set Cross-Origin-Resource-Policy "same-origin"
</IfModule>

Replace "same-origin" with "same-site" or "cross-origin" as needed.

3. Reload/Restart Apache:

systemctl restart apache2

service apache2 restart

1. Open Your Nginx Configuration:

Edit /etc/nginx/nginx.conf or a site-specific config in /etc/nginx/sites-available/:

server {
    listen 80;
    server_name example.com;

    location / {
        add_header Cross-Origin-Resource-Policy same-origin always;
        # ...other directives...
    }
}

2. Test Your Configuration:

nginx -t

3. Reload/Restart Nginx:

systemctl reload nginx

service nginx reload

Note: The always parameter is important to ensure the header is added to all responses, including error pages.

Using IIS Manager

Open IIS Manager and select your website.
Open the "HTTP Response Headers" Feature.
Add a New Header:
- Name: Cross-Origin-Resource-Policy
- Value: same-origin
Apply changes and restart the site if needed.

Using web.config

If you prefer to edit the web.config directly, add:

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Cross-Origin-Resource-Policy" value="same-origin" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Additional Insight on CORP and Isolation

Cross-Origin-Embedder-Policy (COEP) is closely related to CORP. If you set a COEP header (e.g., Cross-Origin-Embedder-Policy: require-corp), it will demand that embedded resources explicitly opt-in to cross-origin sharing by including the CORP header or appropriate CORS headers. This helps achieve a higher level of isolation, which browsers may require for powerful features like high-resolution timers or SharedArrayBuffer.

CDN Tip: If you maintain a CDN or any publicly consumable assets, consider explicitly setting:

Cross-Origin-Resource-Policy: cross-origin

so you're not accidentally blocking legitimate embedding requests from external sites—or from your own subdomains and ports, if your infrastructure is spread across multiple endpoints.

Final Note

Adopting the Cross-Origin Resource Policy header is an excellent way to reinforce your web security posture. When combined with other headers such as CORS (Access-Control-Allow-Origin) and COEP (Cross-Origin-Embedder-Policy), CORP forms a powerful barrier against data leakage, hotlinking, and side-channel exploits. By customizing CORP values to suit your site's embedding requirements, you can secure sensitive content, support legitimate cross-origin operations, and maintain future-proof protection against emerging threats.

Additional Resources

Learn more about Cross-Origin Resource Policy from these authoritative sources:

MDN Web Docs: Cross-Origin Resource Policy

Mozilla's complete guide to understanding and implementing CORP

web.dev: Make your website "cross-origin isolated"

Google's guide to implementing CORP as part of a cross-origin isolation strategy

Resource Policy Explainer

Interactive guide to understanding CORP, CORS, and COEP

W3C: Cross-Origin Resource Policy

Technical specification for the CORP header from W3C

Chrome Developers: Enabling SharedArrayBuffer

How CORP fits into enabling powerful features like SharedArrayBuffer

Related Security Headers

Learn about other HTTP security headers to strengthen your website's security: