En-tête Cross-Origin-Embedder-Policy (COEP)

Syntaxe

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

Directives

unsafe-none

Autorise le document à charger des ressources d'origine croisée sans autorisation explicite via le protocole CORS ou l'en-tête Cross-Origin-Resource-Policy. Il s'agit de la valeur par défaut.

require-corp

Un document ne peut charger que des ressources de même origine, ou des ressources explicitement marquées comme chargeables depuis une autre origine.

Le chargement de ressources d'origine croisée sera bloqué par COEP sauf si :

• La ressource est demandée en mode no-cors et la réponse inclut un en-tête Cross-Origin-Resource-Policy qui autorise son chargement dans l'origine du document.
• La ressource est demandée en mode cors et la ressource prend en charge et autorise CORS. Cela peut se faire, par exemple, en HTML avec l'attribut crossorigin, ou en JavaScript en effectuant une requête avec {mode="cors"}.

credentialless

Un document peut charger des ressources d'origine croisée demandées en mode no-cors sans autorisation explicite via l'en-tête Cross-Origin-Resource-Policy. Dans ce cas, les requêtes sont envoyées sans identifiants : les cookies sont omis dans la requête et ignorés dans la réponse.

Le comportement de chargement cross-origin pour les autres modes de requête est identique à celui de require-corp. Par exemple, une ressource d'origine croisée demandée en mode cors doit prendre en charge (et autoriser) CORS.

Exemples

Fonctionnalités dépendant de l'isolation inter-origines

Certaines fonctionnalités, comme l'accès aux objets SharedArrayBuffer ou l'utilisation de Performance.now() avec des minuteurs non limités, ne sont disponibles que si votre document est isolé inter-origines.

Pour utiliser ces fonctionnalités dans un document, vous devez définir l'en-tête COEP avec la valeur require-corp ou credentialless, et l'en-tête Cross-Origin-Opener-Policy à same-origin. De plus, la fonctionnalité ne doit pas être bloquée par Permissions-Policy: cross-origin-isolated.

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

Vous pouvez utiliser les propriétés Window.crossOriginIsolated et WorkerGlobalScope.crossOriginIsolated pour vérifier si les fonctionnalités sont restreintes respectivement dans les contextes window et worker :

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);
}

Éviter le blocage COEP avec CORS

Si vous activez COEP avec require-corp et souhaitez intégrer une ressource d'origine croisée qui prend en charge CORS, vous devrez explicitement indiquer qu'elle est demandée en mode cors.

Par exemple, pour récupérer une image déclarée en HTML depuis un site tiers qui prend en charge CORS, vous pouvez utiliser l'attribut crossorigin afin qu'elle soit demandée en mode cors :

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

Vous pouvez de la même façon utiliser l'attribut HTMLScriptElement.crossOrigin ou effectuer une requête avec { mode: 'cors' } pour demander un fichier en mode CORS en JavaScript.

Si CORS n'est pas pris en charge pour certaines images, une valeur COEP de credentialless peut être utilisée comme alternative pour charger l'image sans consentement explicite du serveur distant, au prix d'une requête sans cookies.

Spécifications

Compatibilité des navigateurs

Voir aussi

• L'en-tête Cross-Origin-Opener-Policy
• Les propriétés API Window.crossOriginIsolated et WorkerGlobalScope.crossOriginIsolated
• Cross Origin Opener Policy ^(angl.) dans Why you need "cross-origin isolated" for powerful features sur web.dev (2020)
• COOP et COEP expliqué : Artur Janc, Charlie Reis, Anne van Kesteren ^(angl.) (2020)