Cross Origin Resource Policy

Protect your web applications from speculative side-channel attacks and cross-origin data leakage with CORP HTTP security headers

What is Cross-Origin Resource Policy?

Cross-Origin Resource Policy (CORP) is an HTTP security header that provides an additional layer of protection for web resources by controlling which origins can include them in cross-origin requests. Developed as a direct response to speculative side-channel attacks like Spectre and Meltdown, CORP enables websites to explicitly opt in to protection against certain cross-origin requests, preventing unauthorized cross-origin access to sensitive resources and mitigating risks associated with cross-site scripting inclusion attacks.

The fundamental purpose of CORP is to give servers granular control over who can access their resources across origins. By setting the appropriate policy value, servers can restrict resource access to same-origin requests only, same-site requests, or explicitly allow cross-origin access. This mechanism is particularly valuable for protecting API endpoints, sensitive data responses, and any resources that should not be accessed from untrusted cross-origin contexts.

For web applications handling confidential data, implementing CORP alongside other security headers creates a robust defense-in-depth strategy that protects against both traditional web vulnerabilities and hardware-level attacks.

The Three Policy Values

same-origin

The same-origin value is the most restrictive option available for CORP. When a resource is served with this policy, only requests originating from the exact same origin can successfully retrieve the resource. Any cross-origin request, whether from a different subdomain, different port, or entirely different domain, will be blocked by the browser.

This policy is appropriate for highly sensitive resources that should never be accessed from any other context. Authentication tokens, private API responses containing user-specific data, and administrative endpoints are strong candidates for same-origin protection. The implementation is straightforward: include the header Cross-Origin-Resource-Policy: same-origin in the HTTP response for the protected resource.

same-site

The same-site value provides slightly more flexibility by allowing requests from any origin that shares the same registrable domain. This means that resources served with same-site can be accessed by all subdomains of the primary domain. This approach is common in microservices architectures where multiple services share a common domain.

cross-origin

The cross-origin value explicitly permits requests from any origin, effectively disabling CORP protection for the resource. This value serves a specific purpose in the context of cross-origin isolation, particularly when combined with COEP (Cross-Origin Embedder Policy) to enable powerful features like SharedArrayBuffer.

Security Threats CORP Addresses

Understanding the vulnerabilities that Cross-Origin Resource Policy helps prevent

Spectre and Meltdown

Hardware vulnerabilities that allowed malicious code to read sensitive data from memory. CORP prevents cross-origin data leakage through speculative execution attacks.

Cross-Site Script Inclusion

XSSI attacks that exploit cross-origin resource requests to extract sensitive data. CORP ensures unauthorized origins cannot read response contents.

Side-Channel Attacks

Timing-based attacks that can infer sensitive information from resource loading patterns. CORP blocks unauthorized access that could enable these attacks.

Implementation Best Practices

Setting the Header Correctly

The Cross-Origin-Resource-Policy header is set as an HTTP response header on the resources you wish to protect. The header syntax is straightforward: Cross-Origin-Resource-Policy: <value>.

Common Configuration Pitfalls

  • Accidentally blocking legitimate traffic: Using same-origin when same-site is needed for microservices communication
  • Preflight request confusion: Understanding how CORP interacts with CORS preflight requests
  • Inconsistent application: Applying CORP to some resources but not others where needed

Testing Your Implementation

Verify CORP implementation using browser DevTools, automated security scanners, and integration tests that confirm legitimate cross-origin requests continue working. Tools like securityheaders.com can audit your security header configuration across your entire site.

Cross-Origin Opener Policy controls which origins can access your browsing context. While CORP protects resource reading, COOP protects window references. Setting Cross-Origin-Opener-Policy: same-origin ensures only same-origin documents can have direct references to your window.

Single-Page Applications

For SPAs with separate frontend and backend origins, use `same-site` if sharing a domain, or implement proper CORS alongside CORP for true cross-origin setups.

Microservices

Set `same-site` on all internal services to allow legitimate inter-service communication while blocking external access. Simplifies with consistent domain structure.

CDN Usage

Public static assets use `cross-origin`. Private sensitive assets use `same-origin`. Configure CDN headers appropriately for each content type.

Public APIs

Combine CORS for access control with `cross-origin` CORP value. Use CORS to restrict which origins can make requests while enabling cross-origin isolation.

Server Configuration Examples
1# Nginx configuration2add_header Cross-Origin-Resource-Policy "same-origin" always;3 4# Apache configuration5Header always set Cross-Origin-Resource-Policy "same-origin"6 7# Node.js/Express8res.setHeader('Cross-Origin-Resource-Policy', 'same-origin');9 10# Example: Multiple policy values for different routes11# Sensitive API endpoint - same-origin only12location /api/private {13 add_header Cross-Origin-Resource-Policy "same-origin";14}15 16# Public assets - cross-origin for CDN/embed usage17location /public {18 add_header Cross-Origin-Resource-Policy "cross-origin";19}20 21# Internal services - same-site for subdomain access22location /api/internal {23 add_header Cross-Origin-Resource-Policy "same-site";24}

Frequently Asked Questions

Secure Your Web Applications

Implement comprehensive security headers including CORP, COOP, and COEP to protect against modern web vulnerabilities.

Sources

  1. MDN Web Docs: Cross-Origin Resource Policy - Comprehensive technical documentation from Mozilla covering the official specification
  2. web.dev: Security Headers Quick Reference - Google's official developer guidance on security headers including CORP
  3. Okta Developer: Security Headers Best Practices - Industry perspective on implementing security headers
  4. Fetch Specification - Cross-Origin-Resource-Policy Header - Official web standard