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: