Cross-Origin-Embedder-Policy-Report-Only (COEP) header
The HTTP Cross-Origin-Embedder-Policy-Report-Only (COEP) response header configures the current document's report-only policy for loading and embedding cross-origin resources that are requested in no-cors mode.
The header allows website administrators to report on resources that would be blocked by Cross-Origin-Embedder-Policy, without preventing them from being loaded.
This allows for a softer rollout of enforcement.
Violations of the policy may be reported using the Reporting API.
Reports can be observed in the page for which the policy is being set using a ReportingObserver, and sent to server endpoints defined in a Reporting-Endpoints HTTP response header, and selected using the report-to parameter.
For more information see COEPViolationReport.
| Header type | Response header |
|---|
Syntax
Cross-Origin-Embedder-Policy-Report-Only: <token>; <parameter>
Directives
The header should only be set with just one token and a report-to endpoint.
Setting the header more than once or with multiple tokens is equivalent to setting unsafe-none.
Omitting report-to makes the header functionally inert.
The <token> value can be one of:
unsafe-none-
Allows the document to load cross-origin resources requested in
no-corsmode without giving explicit permission through theCross-Origin-Resource-Policyheader. This is the default value. require-corp-
A document can only load resources requested in
no-corsmode from the same origin, or resources that have explicitly set theCross-Origin-Resource-Policyheader to a value that allows it to be embedded.Cross-origin resource loading will be blocked by COEP unless:
- The resource is requested in
no-corsmode and the response includes aCross-Origin-Resource-Policyheader that allows it to be loaded into the document origin. - The resource is requested in
corsmode; for example, in HTML using thecrossoriginattribute, or in JavaScript by making a request with{mode="cors"}. Note that requests made incorsmode won't be blocked by COEP or trigger COEP violations, but must still be permitted by CORS.
- The resource is requested in
credentialless-
A document can load cross-origin resources that are requested in
no-corsmode without an explicit permission via theCross-Origin-Resource-Policyheader. In this case requests are sent without credentials: cookies are omitted in the request, and ignored in the response.The cross-origin loading behavior for other request modes is the same as for
require-corp. For example, a cross-origin resource requested incorsmode must support (and be permitted by) CORS.
The <parameter> is optional, and can be one of:
report-to <endpoint_name>Optional-
The
<endpoint_name>is the name of the endpoint to which policy violations will be sent. The mapping between the name and a particular endpoint is defined separately in theReporting-EndpointsHTTP header.
Specifications
| Specification |
|---|
| HTML # coep |
Browser compatibility
| desktop | mobile | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cross-Origin-Embedder-Policy
|
|
|
|
|
|
|
|
|
|
|
|
|
credentialless
|
|
|
|
|
|
|
|
|
|
|
|
|
report-to parameter
|
|
|
|
|
|
|
|
|
|
|
|
|
Legend
Tip: you can click/tap on a cell for more information.
- Full support
- Full support
- No support
- No support
- See implementation notes.
See also
Cross-Origin-Embedder-PolicyCross-Origin-Opener-PolicyWindow.crossOriginIsolatedandWorkerGlobalScope.crossOriginIsolatedReportingObserverCOEPViolationReport- Reporting API
- Cross Origin Opener Policy in Why you need "cross-origin isolated" for powerful features on web.dev (2020)
- COOP and COEP explained: Artur Janc, Charlie Reis, Anne van Kesteren (2020)