Cross-Origin-Resource-Policy

TL;DR: Controls which origins can load your resource (images, scripts, etc.). Use same-origin or same-site to protect sensitive resources, cross-origin for public CDN assets.

What is Cross-Origin-Resource-Policy?

The Cross-Origin-Resource-Policy (CORP) header controls who can load a resource in no-cors contexts such as images, scripts, styles, and fonts.

It is a resource-side protection: the server that owns the asset decides whether that asset can be embedded cross-origin.

Why CORP Exists

CORP helps reduce cross-origin data exposure and Spectre-style side-channel risk by blocking unintended embedding of sensitive resources.

Typical use cases:

• Block internal API JSON from being embedded elsewhere
• Limit sensitive files to same-origin or same-site consumers
• Keep public CDN assets available cross-origin

Syntax

Cross-Origin-Resource-Policy: same-site
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Resource-Policy: cross-origin
```text

## Value Guide

- `same-origin`: only exact origin can load the resource
- `same-site`: any subdomain in same site can load it
- `cross-origin`: any origin may load it

## Example

```http
HTTP/1.1 200 OK
Cross-Origin-Resource-Policy: same-origin
Content-Type: application/json

Practical Deployment Pattern

Use stricter values for private data, looser values for public assets:

# Sensitive API response
Cross-Origin-Resource-Policy: same-origin

# Shared static assets
Cross-Origin-Resource-Policy: cross-origin
```text

## Implementation

```javascript
// Protect API responses
app.use('/api', (req, res, next) => {
  res.setHeader('Cross-Origin-Resource-Policy', 'same-origin')
  next()
})

// Allow CDN resources
app.use('/cdn', (req, res, next) => {
  res.setHeader('Cross-Origin-Resource-Policy', 'cross-origin')
  next()
})

CORP vs CORS

CORP and CORS solve different problems:

• CORP controls whether a resource can be embedded/loaded cross-origin
• CORS controls whether cross-origin JavaScript can read response data

In many apps you use both:

• Access-Control-Allow-Origin
• Cross-Origin-Embedder-Policy

Common Mistakes

• Setting same-origin on assets that must be shared from a CDN
• Assuming CORP alone enables cross-origin JavaScript API access
• Forgetting to test embedded third-party resources after tightening policy

Related Headers

• Cross-Origin-Embedder-Policy
• Cross-Origin-Opener-Policy

CORP vs CORS: Different Problems, Different Solutions

Cross-Origin-Resource-Policy and CORS solve related but distinct problems. CORS controls whether cross-origin JavaScript can read the response body of a fetch or XHR request. CORP controls whether a resource can be loaded at all in cross-origin contexts like <img>, <script>, <link>, and <iframe> tags.

A resource can have CORS headers but no CORP header, which means JavaScript can read it cross-origin but it can also be embedded in any page. A resource can have CORP but no CORS headers, which means it can only be embedded by allowed origins but JavaScript cannot read its response body cross-origin. For maximum control, use both.

The practical deployment pattern is to set Cross-Origin-Resource-Policy: same-origin on sensitive API responses and internal resources, and Cross-Origin-Resource-Policy: cross-origin on public CDN assets that need to be embeddable anywhere. For resources that should be accessible to a specific set of partner domains, same-site is the right value if those domains share a registrable domain, otherwise you need CORS headers for JavaScript access and cannot restrict embedding to specific third-party origins with CORP alone.