HTTP Headers

Cross Origin Embedder Policy

HTTP Header

The HTTP Cross-Origin-Embedder-Policy response header configures the current document’s policy for loading and embedding cross-origin resources.

The policy determining whether a specific resource can be embedded cross-site can be defined for that resource using the Cross-Origin-Resource-Policy (CORP) header for a no-cors fetch, or through CORS.
If neither of these policies are set, resources are loaded or embedded into a document as if they had a CORP value of cross-site.

The Cross-Origin-Embedder-Policy enables you to mandate that CORP or CORS headers must be present for loading cross-site resources into the current document.
You can also configure the policy to maintain the default behavior or to allow resources to load while stripping any credentials that might otherwise be sent.
This policy applies to loaded resources, <iframe> elements, and nested frames.

Note:
The Cross-Origin-Embedder-Policy does not override or influence the embedding behavior for resources restricted by CORP or CORS.
If CORP limits a resource to being embedded only same-origin, it will not be loaded cross-origin regardless of the COEP value.

Header type	Response header
Forbidden response header name	No

Syntax

Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless

Directives

unsafe-none

This directive allows the document to load resources from other origins without explicitly permitting it through the CORS protocol or the Cross-Origin-Resource-Policy header. It is the default setting.

require-corp

With this directive, a document can only load resources from the same origin or resources that are explicitly marked as loadable from different origins.

Cross-origin resource sharing will be blocked unless:

- The resource is requested using no-cors mode, and the response contains a Cross-Origin-Resource-Policy header permitting it to be loaded.

- The resource is requested in cors mode, and the resource supports and is authorized by the CORS policy. This can be specified in HTML with the crossorigin attribute or in JavaScript by making a fetch request with mode set to “cors”.

credentialless

This directive allows loading cross-origin resources requested in no-cors mode without explicit permission via the Cross-Origin-Resource-Policy header. In this mode, requests are sent without credentials such as cookies, which are omitted in the request and ignored in the response.

The behavior for other request modes, like cors, remains the same as with require-corp. For example, a cross-origin resource in cors mode must support and permit CORS.

Example

Features that depend on cross-origin isolation
Certain features, such as access to SharedArrayBuffer objects or using Performance.now() with unthrottled timers, are only available if your document is cross-origin isolated.
To use these features in a document, you will need to set the COEP header with a value of require-corp or credentialless, and the Cross-Origin-Opener-Policy header to same-origin.
In addition, the feature must not be blocked by Permissions-Policy: cross-origin-isolated.

HTTP Example:

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

You can use the Window.crossOriginIsolated and WorkerGlobalScope.crossOriginIsolated properties to check if the features are restricted in window and worker contexts, respectively:

JavaScript Example:

const myWorker = new Worker("worker.js");
if (crossOriginIsolated) {
 const buffer = new SharedArrayBuffer(16);
 myWorker.postMessage(buffer);
} else {
 const buffer = new ArrayBuffer(16);
 myWorker.postMessage(buffer);
}

Avoiding COEP blockage with CORS
If you enable COEP using require-corp and want to embed a cross-origin resource that supports CORS, you will need to explicitly specify that it is requested in cors mode.

For example, to fetch an image declared in HTML from a third-party site that supports CORS, you can use the crossorigin attribute so that it is requested in cors mode:

HTML Example:

<img src="https://thirdparty.com/img.png" crossorigin />

You can similarly use the HTMLScriptElement.crossOrigin attribute or fetch with { mode: 'cors' } to request a file in CORS mode using JavaScript.

If CORS is not supported for some images, a COEP value of credentialless can be used as an alternative to load the image without any explicit opt-in from the cross-origin server, at the cost of requesting it without cookies.

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Cross Origin Embedder Policy header. This can be very helpful when you want to control how your web application handles cross-origin resources, especially for enabling powerful web features like SharedArrayBuffer or improving security. Steps to Modify the Cross Origin Embedder Policy Header:

Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Cross-Origin-Embedder-Policy.
- In the “Header Value” field, enter your desired policy value (e.g., require-corp).
Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-website.com/*).
Save the rule.

After this setup, Requestly will inject the specified Cross-Origin-Embedder-Policy header into all matching requests, enabling you to test how your site behaves under different embedding policies.

Cross Origin Embedder Policy

Syntax

Directives

Example

How to Modify Header using Requestly

Level up your dev Game