Really Simple SSL

Cross Origin Security Headers

Table of Contents

Cross-Origin Security Headers

Really Simple SSL Pro now offers four new security headers, all related to Cross-Origin security. These headers will be released in several stages, in increasing complexity. We have now released the first stage, with the most simple options. The below instructions apply to Really Simple SSL pro 5.2.5, which will be released soon.
As these headers may break functionality on a site, we’ve decided to roll out these features in several minimum impact steps, and process feedback on these new features between each step.

The new headers are Cross-Origin Resource Sharing (CORS), Cross-Origin Resource Policy (CORP), Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Opener-Policy (COOP). These headers prevent several types of attack, the most important of these is Spectre. 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, amongs others same-site, same-origin and cross-origin. To understand the implications I’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)

Possible values: * or domain. Also possible: same-site, same-origin or cross-origin
The CORS header determines if other websites can load resources from this domain or not. If you set it to cross-origin, other websites can use this website’s resources.
If the site is used as a resource for other websites that use the COEP header, the header should be set to ‘cross-origin’. The default is same-site. This means resources can only load from the same domain.
It is important to note that these headers are enforced by the client, which in case of a website is usually the browser. This means that if you think about the implications for your website, you should keep in mind that the applications that use these resources from your site, only will have an issue if the application is loaded in a browser. For example: if a website uses license checking, and the license is checked from a web application in a browser, the CORS header must be set to cross-origin. If the end-user submits a license from the browser to the server, and the server does the request to your website, the CORS header can be same-site.
For most users we recommend to set this to same-site, which is the default in Really Simple SSL pro.

Cross-Origin Resource Policy (CORP)

Possible values: same-site, same-origin, cross-origin
If the site is used as resource for other websites that use the COEP header, 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-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 CORS cross-origin header. As there aren’t many third-party resources with this header yet, we have by default implemented credentialless. This option allows the usage of COEP without completely blocking third party resources that do not send the CORP cross origin header.

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.

A quick decision tree for these headers is as follows:

  • Your site is used as resource on other websites =>
    • yes, third party websites=> CORS, CORP set to cross-origin.
    • yes, but only your own subdomains=> CORS, CORP set to same-site
    • no=> CORS, CORP set to same-origin
  • In all cases=> Do not use CORP if PDFs are used, because of the Chrome bug.
  • COEP: Your site uses third party resources
    • yes, and the HTML elements with the resources contain an attribute ‘crossorigin’, the resources send a CORS:cross-origin header => COEP set to require-corp
    • yes, but resources do not have the CORS:cross-origin header => COEP set to credentialless
    • no => COEP to require-corp.
  • COOP. our 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. Like for example the plugin thumbnails are loads from a third party without cross-origin header. This means we cannot use COEP with require-corp. Summarising, we can state the following as practical use case:

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


Related articles

4 Responses

  1. If I may say so, the article is not very clear, as I see it. For example, if “Cross-Origin” does not check any of the three parts of the URL, how is it different from “Disabled”? There is no mention of the “Disabled” option in the description.

    Also, it is not clear how the four added headers (CORS etc.) relate to the combined dropdown.

    Maybe a table could be useful, showing the setting for each of the four headers based on the three possible settings of the dropdown?

    This seems to be a useful feature set that was added, but of course we need to understand how to use it in order to get the benefit.

    1. Agree with David Alexander. Great feature but lacks some clarity and perhaps for the less technical, some recommendations based on usage.

  2. para una persona que hace marketing digital,con dominio propio promoviendo productos digitales
    cuales son los servicios que recomiendan para las personas que trabajan en lo que eh mencionado anteriormente

Comments are closed.

Join our mailing list - 8 Tips & Tricks in your inbox over the next 8 weeks!

Integrate with Really Simple SSL

Really Simple SSL offers a Free SSL Certificate from Let’s Encrypt. Do you want to integrate with Really Simple SSL as a hosting provider? Let us know!

Choose the answer that most closely resembles your proposed integration. Additional information can be entered below.
After sending the form. The pop-up will close automatically.