Consider deploying
Cross-Origin Resource Policy
The
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: same-origin, same-site, and
cross-origin. Let's look at each:
§
Limit usage with same-origin or same-site
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:
Cross-Origin-Resource-Policy: same-origin
Some applications can't lock themselves to a single origin, as they rely on resources shared
within a particular site. For example, consider mail.example.com and
www.example.com, which both rely on single-sign-on.example.com for
authentication, and cdn.example.com for static resources. These latter two origins
could not set same-origin, but they can set:
Cross-Origin-Resource-Policy: same-site
§
Broadly allow usage with cross-origin
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:
Cross-Origin-Resource-Policy: cross-origin§ CORP and Isolation
Today, browsers act as though
Cross-Origin-Resource-Policy: cross-origin
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 same-origin,
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
Cross-Origin-Embedder-Policy
header, which will prevent them from loading cross-origin resources that don't explicitly
assert
Cross-Origin-Resource-Policy: cross-origin
(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 performance.now() or SharedArrayBuffer).
With this in mind, it seems likely that usage of
Cross-Origin-Embedder-Policy will increase over time, and therefore
that 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.
FAQ
I already assert Access-Control-Allow-Origin: *
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 cors and 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-Opener-Policy, andCross-Origin-Embedder-Policy, which form the technical basis of the opt-in. - The Fetch specification defines the
Cross-Origin-Resource-Policyheader.