Cross-Origin Resource Policy
(CORP) header allows you to control the set of
origins that are empowered to include a resource. It is a robust defense against attacks like
Spectre, as it allows browsers to block a given response
before it enters an attacker's process.
The header has three values:
cross-origin. Let's look at each:
Limit usage with
If a resource contains interesting information about a user, or is a response from an API that you don't intend for others to use, then it's quite likely that you would be well-served by asking the browser to ensure that it can't leak into cross-origin contexts by adding the following response header to the relevant resources:
Some applications can't lock themselves to a single origin, as they rely on resources shared
within a particular site. For example, consider
www.example.com, which both rely on
cdn.example.com for static resources. These latter two origins
could not set
same-origin, but they can set:
Broadly allow usage with
Do you serve resources that you want other sites to embed? Perhaps you're running a widely-used CDN? Perhaps you're running an in-house CDN for a small suite of related sites? Perhaps you own a third-party widget that you want to be used broadly? In all these cases, you'll want to make the expectation explicit by adding the following response header to the relevant resources:
§ CORP and Isolation
Today, browsers act as though
is set on every response that lacks an explicit CORP
header. This is a somewhat unfortunate default, and browsers are interested in shifting the
behavior for these resources to something more like
which will protect resources unless they explicitly opt-into being shared more widely. That
shift is going to take some time, however.
In the meantime, developers can opt-into a better default for their own pages by sending a
header, which will prevent them from loading cross-origin resources that don't explicitly
(or grant full access via CORS. Over time,
browsers will begin requiring pages to
opt-into cross-origin isolation
in order to access certain features that make side-channel attacks more effective (for example,
high-resolution timers like
With this in mind, it seems likely that usage of
Cross-Origin-Embedder-Policy will increase over time, and therefore
Cross-Origin-Resource-Policy will be important to consider when
configuring your server.
In particular, if you host resources that others depend upon, it would be an excellent idea to explicitly assert a cross-origin resource policy so that you're not a roadblock to isolation. Happily, doing so is pretty straightforward, and supported in all modern browsers. Even more happily, the assertion has no effect in pre-modern browsers, so should be safe to roll out for all your users.
I already assert
for public resources. Do I need to add CORP too?
That depends on the folks that depend on you.
ACAO: * only takes effect for requests
that were made as CORS requests, and which explicitly dropped credentials. That is,
<script ... crossorigin="anonymous"> will continue working, but
<script> will fail for developers who opt-into isolation.
You can determine how many folks are making CORS-enabled requests by taking a look at incoming
Sec-Fetch-Mode headers from browsers that support
Fetch Metadata. It seems likely
that you'll see a mix of
no-cors requests. The former will
continue working for isolated sites, the latter will not.
Do modern browsers support CORP? §
Yes! The three major browser engines all support the header. Safari 12 was the first to support the header, followed by Firefox 74 and Chrome 73. Chromium-based browsers like Edge should support it as well. A more detailed support chart is available from the good folks at Can I use...
Where can I read more about this isolation thing? §
There are a few good resources to check out:
- "Making your website 'cross-origin isolated' using COOP and COEP" is an approachable introduction.
- Chromium's "Post-Spectre Threat Model Re-Think" is a good introduction to the core problem that isolation hopes to address.
- "COOP and COEP Explained" is a good primer on
Cross-Origin-Embedder-Policy, which form the technical basis of the opt-in.
- The Fetch specification defines the