A Simple Guide to COOP, COEP, CORP, and CORS

The Spectre and Meltdown attacks exploited vulnerabilities in modern CPUs that allowed hackers to access restricted user data. This could include passwords, personal data, and credit card numbers. In order to prevent these attacks, access to powerful features like SharedArrayBuffer and performance.measureMemory() was removed. In this post, we’ll look at how you can set up your site or application to safely restore access to these powerful APIs with COOP, COEP, CORP, and CORS.

If you are monetizing your website with AdSense, header bidding, or native video it is vital that you correctly configure COOP, COEP, CORP, and CORS. These advertising technologies require frequent access to cross-origin resources which can leave your users vulnerable to attacks. We’ll cover this in more detail below.

What is composability?

Composability enables website owners to load and use resources from other domains. Examples of composability are loading the following resources from another domain or origin:

• Ads
• Fonts
• Videos
• Images
• Maps
• Payment solutions

These resources provide powerful enhancements for websites but their cross-origin nature leads to increased security risks. For example, hackers can trick the browser into loading malicious code from another origin or domain. As a result, browsers keep cross-origin resources separated within a browsing context group to prevent these attacks.

Source: Google

What is the Same-Origin Policy?

The same-origin policy is a security feature that restricts how documents and scripts can interact with resources from another origin. This prevents hackers from using their access to the user’s computer to steal data when malicious code is loaded from another origin. The same-origin policy did a good job of protecting the web except for Spectre.

What is Spectre?

Spectre is a vulnerability found in modern CPUs that allows malicious websites to read the memory on a user’s computer across the origin boundary. Spectre uses high-precision timers or features that can act as high-precision timers like performance.measureMemory(). The same-origin policy is not effective against this kind of attack. Therefore, in order to protect users, access to all features that could act as high-precision timers was removed by browser vendors.

Here’s a short video that shows how the Spectre attack works.

Since the Spectre and Meltdown attacks, developers have been working on a way to safely restore access to these APIs that could otherwise be maliciously used to gather user data.

What is Cross-Origin Isolated?

Cross-origin isolated is a new security feature that provides increased isolation from other origins. By isolating cross-origin resources into separate browsing context groups, Spectre and other vulnerabilities are no longer able to read cross-origin contexts. To achieve cross-origin isolation the browser needs an explicit signal from the web page that says “isolate me from other origins”. This is where COOP and COEP come in.

Why do I need COOP and COEP?

To opt-in to a cross-origin isolated state, you need to send the following HTTP headers on the main document:

Cross-Origin-Embedder-Policy: require-corp

Cross-Origin-Opener-Policy: same-origin

These headers instruct the browser to block resources or iframes that haven’t opted into being loaded by cross-origin documents. They also prevent cross-origin windows from directly interacting with your document. This also means any resources being loaded cross-origin will require opt-ins. Below we’ll cover further options for these HTTP Response Headers at your disposal.

What is COOP (Cross Origin Opener Policy)?

COOP or Cross Origin Opener Policy is in an HTTP-header-based mechanism that lets you restrict access for cross-origin windows opened from the document. There are 3 configurable levels within COOP:

Cross-Origin-Opener-Policy: (same-origin|same-origin-allow-popups|unsafe-none); report-to=”default”

Source: Google

When COOP is set to same-origin, any cross origin window opened from the document will have no access to the opener’s DOM.

Source: Google

You can test this in Chrome by going to the console (right-click > Inspect > Console) and entering “window.opener”. You should see “null” returned. This is particularly relevant for cross-origin pop-ups.

A top-level document with same-origin-allow-popups retains references to all of its popups which either don’t set COOP or opt out of isolation by setting a COOP of unsafe-none.

Source: Google

unsafe-none is the default and allows the document to be added to its opener’s browsing context group unless the opener has a COOP of same-origin.

What is COEP (Cross Origin Embedder Policy)?

COEP or Cross Origin Embedder Policy is an HTTP-header based mechanism that prevents a document from loading cross-origin resources that don’t explicitly grant the document permission with CORP or CORS. COEP lets you declare that a document cannot load these resources.

To activate this policy, append the following HTTP header to the document:

Cross-Origin-Embedder-Policy: require-corp

Source: Google

Want more details on COOP and COEP? There’s a great article here from a few Google devs.

What is CORP (Cross Origin Resource Policy)?

CORP or Cross Origin Resource Policy is an HTTP-header-based mechanism to protect your resources from being loaded by another origin. CORP can set the resource owner’s policy for who can load a resource.

The Cross-Origin-Resource-Policy header takes three possible values:

Cross-Origin-Resource-Policy: same-site

Resources that are marked same-site can only be loaded from the same site.

Cross-Origin-Resource-Policy: same-origin

Resources that are marked same-origin can only be loaded from the same origin.

Cross-Origin-Resource-Policy: cross-origin

Resources that are marked cross-origin can be loaded by any website.

What is CORS?

CORS or Cross Origin Resource Sharing is an HTTP-header based mechanism that allows a server to indicate any origins (other than its own) from which a browser can load resources. For example, https://domain-1.com makes a request to the following image: https://domain-2.com/img/test-image.png. The CORS setting for the resource test-image.png will determine whether the image can be loaded or not by https://domain-1.com .

Mozilla has a detailed article on CORS if you’d like to find out more.

Testing COOP and COEP before deployment

Before fully enabling COEP and COOP, you can do a test using the Cross-Origin-Embedder-Policy-Report-Only and Cross-Origin-Opener-Policy-Report-Only headers to see whether the policy works. Google has an in-depth guide here. This will allow you to receive reports without blocking embedded content.

COOP, COEP, CORP, and CORS for websites with advertising

If your website uses display or video advertising technology, it will frequently load resources from other origins. Websites using header bidding will need to load JavaScript from their header bidding providers. As a result, it’s crucial that you correctly configure COOP, COEP, CORP, and CORS to protect the data of your users. If you’d like help ensuring you have the correct setup contact our adops experts here.

Summary

To secure user data from cross-origin vulnerabilities like Spectre, browser makers restricted access to powerful features like SharedArrayBuffer and JS Self-Profiling API. If you want guaranteed access to these features you need to use COEP with the value of require-corp and COOP with the value of same-origin. In the absence of either, the browser will not guarantee sufficient isolation to safely enable those features.