Last Chance: Cyber Monday 40% OFF



Tackle WordPress weaknesses and fortify your website Learn more

Cross-Origin Isolation

In 2018, a new vulnerability was discovered in processors. It allowed a “side channel attack”. These types of attacks try to gather information by measuring the indirect effects of the system, like speed and power consumption. You can compare it to how you track the speed of a car. Instead of following it with GPS, it tries to track the speed by the gas consumption. An example on the web is Spectre. Spectre exploits a processor design flaw with javascript to trick a program into accessing arbitrary locations in the memory space, including personal sensitive data. For more details, please also check

To close the Spectre vulnerability, some features were removed from browsers. If your site uses an API which uses for example the sharedArrayBuffer() or high precision timer functionality, Cross Origin Isolation is required to unlock these features. This can be achieved with a combination of Cross-Origin Resource Sharing (CORS), Cross-Origin Resource Policy (CORP) and Cross-Origin-Opener-Policy (COOP).

The usage of certain web APIs may increase the risk of attacks such as Spectre. To reduce that risk these new headers try to reach “cross-origin isolation”. This is not possible for all configurations, but each added header improves your website’s security.

These headers can have several values, among others same-site, same-origin and cross-origin. To understand the implications we’ll explain these possible values first.
The difference between same-origin and cross-origin can be explained best in the following way:

An URL ( consists of three elements:

  • (the protocol)
  • (domain)
  • (optional)( (port)

The port is by default 443 when the protocol is https, and 80 when the protocol is http. This means that when we look at, the port 443 is implicitly used.


Same-origin checks if all URL parts match ( This means that with the same-origin attribute and do not match because the protocol is different. The same goes from https:// and https://www . These aren’t the same origin because the protocol does not match. The cross-origin attribute will work in this case because the domain matches.


Same-site checks only if the domain matches. Different protocol, port, or even subdomain are all within the same-site limit.


Cross-origin does not check the protocol, domain and port. Therefore this setting will allow requests from all domains.

Cross-Origin Resource Sharing (CORS)

This header mainly applies to third party ajax and api calls web apps.  It has to be set dynamically, on a per page basis, which makes it only usable when set in PHP, not in .htaccess or nginx.conf. As use cases within WordPress are limited, we recommend using the CORP header instead, when possible.

Cross-Origin Resource Policy (CORP)

Possible values: same-site, same-origin, cross-origin
If the site is used as resource for other websites, the header should be set to ‘cross-origin’.
Please note that a bug in Chrome can cause issues with PDF files not fully rendering. If your site hosts PDFs, set the policy to disabled.

The recommended value is same-origin.

Cross-Origin-Opener-Policy (COOP)

Possible values: same-origin, same-origin-allow-popups, unsafe-none
The Cross-Origin-Opener-Policy (COOP) security header allows you to isolate browsing context between cross-origin documents (for example a popup). Typically each browser window (and for example an iframe) has a browsing context. Generally browsing context can be seen as each window that is presented to the user. The COOP header can define which windows share a browsing context.

Cross-Origin-Embedder-Policy (COEP)

Possible values: unsafe-none, require-corp or credentialles (new)
The Cross-Origin-Embedder-Policy security header prevents a webpage from loading any resources that don’t have the CORP  header. As there aren’t many third-party resources with this header yet, this is not implemented at this moment.

Practical usage in WordPress

A quick decision tree for these headers is as follows:

  • Your site is used as resource on other websites =>
    • yes, third party websites=> CORP set to cross-origin.
    • yes, but only your own subdomains=> CORP set to same-site
    • no=>CORP set to same-origin
  • In all cases=> Do not use CORP if PDFs are used, because of the Chrome bug.
  • COOP. Your site uses popups which require data transfer across the windows
    • yes, and these popups are used on, or from subdomains => same-site.
    • yes, without subdomains => same-origin-allow-popups
    • no => same-site

Within WordPress, there are several things we already know about the implementation. Summarising, we can state the following as practical for use in WordPress:

  • COOP: Your site uses popups
    • yes => same-origin-allow-popups
    • no => same-site (best option for cross origin isolation)
  • CORP: Sharing resources with third-parties=>
    • Sharing Off=> CORP set to same-origin
    • Sharing on=> CORP set to cross-origin.
    • Share only with your own domain=>CORP set to same-site
  • In all cases=> Do not use CORP if PDF’s are used, because of the Chrome bug.

Advanced Security

Tackle WordPress weaknesses and fortify your website. New hardening features!


Want to know the in and outs of security jargon? Get to know our features.

Premium support will offer assistance in 24 hours. If you need help, or have any questions just contact our awesome support team/

Related articles