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 AdSenseheader 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.

Illustration of a person browsing a website that has a popup, an iframe, and an image

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”

Illustration of Browser window with COOP same-origin Pop Up

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.

Illustration of Browser window with COOP same-origin Pop Up

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.

Screenshot of the Chrome Developer Console

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

Illustration of a browser window and a user showing how CORP works

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, makes a request to the following image: The CORS setting for the resource test-image.png will determine whether the image can be loaded or not by .

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.


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.

About the Author

Ben is one of Snigel's Co-CEO. He works on business development and marketing - spreading the word about how Snigel can help publishers supercharge their ad revenue.


Let our team of experts assess how Snigel can increase your ad revenue.
We pride ourselves on creating meaningful relationships with our publishers, understanding their priorities and customizing our solutions to meet their unique needs.

Get in touch →

More From Our Blog

google mcm

Google MCM (Multiple Customer Management) in 2023 : Definitive Guide

Google MCM Program (Multiple Customer Management) lets publishers access Google Ad Exchange through a 3rd party. It is the replacement for Google SPM (Scaled Partner Management) and a tool for publishers to increase their ad revenue and gain deeper insight into their Ad Exchange performance. This guide will cover the differences between MCM and SPM […]

google adx vs adsense

Google AdX vs AdSense (2023) Which Is Best For Your Site?

Google AdX and Google AdSense are the two main digital advertising platforms from Google for publishers. Both platforms enable website owners to monetize their traffic, so what’s the difference and what’s why are so many publishers switching? Knowing which platform to use will save you time, development resources, and late-night headaches. Best of all, it […]

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.