# Cross-Origin-Embedder-Policy (/fr/docs/web-security/policies/cross-origin-embedder-policy)



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](/fr/docs/web-security/policies/cross-origin-opener-policy)
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 :

```http
Cross-Origin-Embedder-Policy: require-corp
```

## Comment fonctionne COEP [#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 [#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 [#mode-report-only]

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

```http
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 [#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 [#configurations-non-sûres-à-éviter]

<Callout type="warn">
  `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`.
</Callout>

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 [#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 [#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 [#recommandation]

```http
Cross-Origin-Embedder-Policy: require-corp
```

La [cheat sheet HTTP Headers de l'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
recommande `require-corp`. Quand le support Safari n'est pas une exigence,
[web.dev](https://web.dev/articles/coop-coep) 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 [#reporting]

Ajoutez un paramètre `report-to="..."`, déclarez l'endpoint, et le navigateur émet le
[rapport coep](/fr/docs/web-security/reporting-api/reports/coep) pour chaque ressource bloquée.
CentralCSP collecte le [flux coep](/fr/docs/platform/monitoring/coep).

## Prise en charge par les navigateurs [#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 [#faq]

### Quelle est la différence entre require-corp et credentialless ? [#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 ? [#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](/fr/blog/corp-vs-coep) couvre cet appariement en
profondeur.

## Voir aussi [#voir-aussi]

* [Cross-Origin-Opener-Policy (COOP)](/fr/docs/web-security/policies/cross-origin-opener-policy)
* [rapport coep](/fr/docs/web-security/reporting-api/reports/coep)
* [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Surveillance COEP dans CentralCSP](/fr/docs/platform/monitoring/coep)

## Sources [#sources]

* [MDN, Cross-Origin-Embedder-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Embedder-Policy)
* [web.dev, COOP and COEP](https://web.dev/articles/coop-coep)
* [OWASP HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
