Cross-Origin-Embedder-Policy (COEP), son rôle et comment la configurer

COEP exige que chaque ressource cross-origin donne son accord avant son chargement par le document, et avec COOP active une isolation cross-origin.

Cross-Origin-Embedder-Policy (COEP) exige que chaque ressource cross-origin chargée par un document donne explicitement son accord, via CORP ou CORS. Cela empêche une page d'aspirer silencieusement des données cross-origin, et avec COOP elle place le document dans l'état d'isolation cross-origin dont SharedArrayBuffer et les timers haute résolution ont besoin.

La configuration sûre tient en une seule ligne de header :

Cross-Origin-Embedder-Policy: require-corp

Comment fonctionne COEP

Avec require-corp, chaque sous-ressource cross-origin chargée par la page doit porter un header Cross-Origin-Resource-Policy (ou passer une vérification CORS) ; tout ce qui ne donne pas son accord est bloqué. L'autre valeur, credentialless, prend un chemin différent : elle charge les ressources cross-origin sans credentials (pas de cookies) au lieu d'exiger leur accord, ce qui est plus facile à adopter mais plus faible.

Comment configurer COEP

Valeur	Statut	Effet
`unsafe-none`	❌ Risqué	La valeur par défaut. Aucune exigence ; les ressources cross-origin se chargent comme d'habitude.
`require-corp`	✅ Bon	Chaque ressource cross-origin doit donner son accord via CORP ou CORS, sinon elle est bloquée. Largement prise en charge.
`credentialless`	🧪 Expérimental	Les ressources cross-origin se chargent sans credentials au lieu de donner leur accord. Dans Chrome et Firefox ; pas Safari.

Mode Report-Only

Reporting-Endpoints: coep-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep-endpoint"

Report-Only liste chaque embed qui casserait sous require-corp sans réellement le bloquer, ce qui est indispensable car COEP est la partie difficile d'un déploiement d'isolation cross-origin.

Ce contre quoi il protège

L'embedding cross-origin silencieux, et l'exposition de données qu'il permet, est la menace que COEP traite : il force chaque ressource cross-origin à consentir à son chargement. C'est aussi le prérequis d'une isolation cross-origin sûre, que le navigateur n'accorde que lorsque l'embedding est verrouillé.

Configurations non sûres à éviter

unsafe-none est la valeur par défaut et n'impose rien. L'isolation cross-origin exige require-corp (ou credentialless) plus Cross-Origin-Opener-Policy: same-origin.

Envoyer COEP sans le Cross-Origin-Opener-Policy: same-origin correspondant ne vous donne ni l'isolation ni les fonctionnalités qui en dépendent, une impasse fréquente.

Contournements et limites connus

COEP a besoin que chaque sous-ressource cross-origin coopère (envoie CORP ou passe CORS), donc il peut être difficile à déployer sur une page avec de nombreux tiers qui ne l'ont pas adopté. La valeur credentialless allège cette contrainte mais n'est pas prise en charge dans Safari.

Risques

Appliquer require-corp bloque d'un coup chaque embed non coopérant, ce qui peut faire tomber des polices, des scripts analytics ou des iframes qui n'envoient pas CORP. Utilisez Report-Only pour les repérer et les corriger ou les remplacer avant d'appliquer.

Recommandation

Cross-Origin-Embedder-Policy: require-corp

La cheat sheet HTTP Headers de l'OWASP recommande require-corp. Quand le support Safari n'est pas une exigence, web.dev documente credentialless comme le chemin le moins contraignant, puisque les tiers n'ont pas à donner leur accord. Sur les ressources que vous servez vous-même, définissez Cross-Origin-Resource-Policy: same-site (recommandation OWASP également) pour que vos propres sous-ressources continuent de se charger sous require-corp.

Reporting

Ajoutez un paramètre report-to="...", déclarez l'endpoint, et le navigateur émet le rapport coep pour chaque ressource bloquée. CentralCSP collecte le flux coep.

Prise en charge par les navigateurs

Standard dans le HTML Living Standard ; require-corp est largement pris en charge dans les versions actuelles de Chrome, Firefox et Safari. credentialless est pris en charge dans Chrome et Firefox mais pas dans Safari, donc ce n'est pas une solution multi-navigateurs complète à lui seul. Le paramètre report-to est limité à Chromium.

FAQ

Quelle est la différence entre require-corp et credentialless ?

Ce sont deux valeurs de COEP. require-corp exige que chaque ressource cross-origin donne son accord via CORP ou CORS, sinon le navigateur la bloque. credentialless charge plutôt les ressources cross-origin sans credentials, donc sans cookies, ce qui est plus facile à adopter mais plus faible, et ce n'est pas pris en charge dans Safari.

Comment CORP et COEP fonctionnent-ils ensemble ?

COEP avec require-corp exige que chaque sous-ressource cross-origin donne son accord ; CORP est le header qu'une ressource envoie pour accorder cet accord. Sur les ressources que vous servez vous-même, définissez Cross-Origin-Resource-Policy: same-site pour qu'elles continuent de se charger sous COEP. Le guide CORP vs COEP couvre cet appariement en profondeur.

Cross-Origin-Embedder-Policy