Skip to main content

Use COOP, COEP to create a more secure environment for browsers

· 5 min read

web resource


Composability is a very powerful capability of the Web, you can easily load resources from different sources to enhance the functionality of a Web page, such as: fontimagevideo and so on.

These services are very powerful and convenient, but such a strategy also increases the risk of information leakage, and attackers can use certain means to leak your user information.


Browsers also do a good job of blocking these attacks. We are already familiar with the same-origin policy, which is used to restrict resource access for sites of different origins. For details, you can poke the browser's same-origin policy, and I won't introduce it too much here.

But there are some exceptions to the same-origin policy, any website can load the following resources without restriction:

  • Embed cross domainiframe
  • image、scriptand other resources
  • Open a cross-domain popup using the DOM

For these resources, the browser can separate the cross-domain resources of each site Context Groupunder different , Context Groupand the resources under different s cannot access each other.

A browser Context Groupis a group of tabs, windows or iframes that share the same context. For example, if a website ( https://a.example) opens a popup ( https://b.example), the opener window and the popup share the same browsing context, and they can access DOM APIeach other , eg window.opener.

Spectre Vulnerability

For a long time, these security policies have protected the private data of the website until the Spectrebreach .


SpectreIt is CPUa vulnerability discovered in . By exploiting Spectreit, an attacker can read any resources Context Groupunder .

Especially when using something that needs to interact APIwith :

  • SharedArrayBuffer (required for WebAssembly Threads)
  • performance.measureMemory()
  • JS Self-Profiling API

For this reason, the browser once disabled SharedArrayBufferhigh -risk such as API.

Cross-domain isolation

In order to be able to use these powerful functions and ensure our website resources are more secure, we need to create a cross-domain isolation environment for browsers.


A lot of terminology will be mentioned below, let's list all cross-domain related terms first to prevent confusion later:

  • COEP: Cross Origin Embedder Policy: Cross-Origin Embedder Policy
  • COOP: Cross Origin Opener Policy: Cross-Origin Opener Policy
  • CORP: Cross Origin Resource Policy: Cross-Origin Resource Policy
  • CORS: Cross Origin Resource Sharing: Cross-Origin Resource Sharing
  • CORB: Cross Origin Read Blocking: cross-origin read blocking

We COOP、COEPcan create an isolated environment with .

Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin

Let's take a look at Hedaerthe and how to configure them.

COOP: Cross Origin Resource Policy

COOP: Cross-Origin Opener Policy, corresponding HTTP Headerto Cross-Origin-Opener-Policy.


By COOPsetting to Cross-Origin-Opener-Policy: same-origin, other windows opened from this website from different sources will be isolated in different browsers Context Group, thus creating an isolated environment for resources.


For example, if COOPa site with opens a new cross-domain popup page, its window.openerproperty will be null.

Besides same-origin, COOPthere are two other different values:

Cross-Origin-Opener-Policy: same-origin-allow-popups


same-origin-allow-popupsTop-level pages with will keep references to popups that are either left unset or opted out of isolation COOPby COOPsetting to .unsafe-none

Cross-Origin-Opener-Policy: unsafe-none


unsafe-noneis the default setting, allowing current page and popup page sharing Context Group.


To enable cross-origin isolation, you also first need to make sure that all cross-origin resources are explicitly allowed to load. There are two implementations of this, one is CORPand the other is CORS.


CORS(Cross-domain resource sharing) It is often used when we solve cross-domain problems on a daily basis. We are already very familiar with this. Let's take a look CORP:

Cross-Origin-Resource-Policy: same-site

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

Cross-Origin-Resource-Policy: same-origin

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

Cross-Origin-Resource-Policy: cross-origin

cross-originTagged resources can be loaded by any website.


Note that if it is some general CDNresources , such as image、font、video, etc., it must be set to cross-origin, otherwise, the resources may not be loaded normally.

For cross-origin resources that you can't control, you can manually add the crossoriginattribute .

COEP: Cross Origin Embedder Policy

COOP: Cross-Origin Embedding Program Policy, corresponding to HTTP Headeris Cross-Origin-Embedder -Policy.


Enable Cross-Origin-Embedder-Policy: require-corp, you can have your site load only cross-origin resources that are explicitly marked as shareable, which is the configuration we just mentioned above, or same-origin resources.


For example, the image resource above Cross-Origin-Resource-Policywill .


COEPBefore fully enabling , you can Cross-Origin-Embedder-Policy-Report-Onlycheck if the policy is working properly by using . If there are any non-compliant resources, they will not be prohibited from loading, but will be reported to your server log.

Test whether cross-domain isolation is normal

After COOP、COEPyour configuration is complete, your site should now be in a cross-domain isolation state. You can use self.crossOriginIsolatedto determine whether the isolation state is normal.

if(self.crossOriginIsolated){  // 跨域隔离成功}

Well, you can now happily use haredArrayBuffer, performance.measureMemoryor JS Self-Profiling APIthese powerful APIs~

refer to