En-tête Cross-Origin-Embedder-Policy-Report-Only (COEP)
L'en-tête de réponse HTTP Cross-Origin-Embedder-Policy-Report-Only (COEP) définit la politique rapport seulement du document actuel pour le chargement et l'intégration de ressources inter-origines demandées en mode no-cors.
Cet en-tête permet aux administrateur·ice·s de sites web de signaler les ressources qui seraient bloquées par Cross-Origin-Embedder-Policy, sans pour autant empêcher leur chargement.
Cela permet une mise en œuvre progressive de cette restriction.
Les violations de la politique peuvent être signalées à l'aide de l'API Reporting.
Les rapports peuvent être consultés sur la page pour laquelle la politique est définie à l'aide d'un objet ReportingObserver, puis envoyés vers les points de terminaison serveur définis dans l'en-tête de réponse HTTP Reporting-Endpoints et sélectionnés à l'aide du paramètre report-to.
Pour plus d'informations, voir COEPViolationReport.
| Type d'en-tête | En-tête de réponse |
|---|
Syntaxe
Cross-Origin-Embedder-Policy-Report-Only: <token>; <parameter>
Directives
L'en-tête ne doit être défini qu'avec un seul jeton et un point de terminaison report-to.
Définir l'en-tête plus d'une fois ou avec plusieurs jetons équivaut à définir unsafe-none.
Omettre report-to rend l'en-tête fonctionnellement inactif.
La valeur <token> peut être l'une des suivantes :
unsafe-none-
Permet au document de charger des ressources inter-origines demandées en mode
no-corssans donner une permission explicite via l'en-têteCross-Origin-Resource-Policy. C'est la valeur par défaut. require-corp-
Un document ne peut charger des ressources demandées en mode
no-corsque depuis la même origine, ou des ressources qui ont explicitement défini l'en-têteCross-Origin-Resource-Policyà une valeur qui permet leur intégration.Le chargement de ressources inter-origines sera bloqué par COEP sauf si :
- La ressource est demandée en mode
no-corset la réponse inclut un en-têteCross-Origin-Resource-Policyqui permet de la charger dans l'origine du document. - La ressource est demandée en mode
cors; par exemple, en HTML en utilisant l'attributcrossorigin, ou en JavaScript en effectuant une requête avec{mode="cors"}. Notez que les requêtes effectuées en modecorsne seront pas bloquées par COEP ni ne déclencheront des violations COEP, mais doivent toujours être autorisées par CORS.
- La ressource est demandée en mode
credentialless-
Un document peut charger des ressources inter-origines demandées en mode
no-corssans donner une permission explicite par l'en-têteCross-Origin-Resource-Policy. Dans ce cas, les requêtes sont envoyées sans informations d'identification : les cookies sont omis dans la requête et ignorés dans la réponse.Le comportement de chargement inter-origines pour les autres modes de requête est le même que pour
require-corp. Par exemple, une ressource inter-origine demandée en modecorsdoit être prise en charge (et autorisée) par CORS.
Le <parameter> est optionnel et peut être l'un des suivants :
report-to <endpoint_name>Facultatif-
<endpoint_name>est le nom du point de terminaison vers lequel les violations de la politique seront envoyées. La correspondance entre le nom et un point de terminaison particulier est définie séparément dans l'en-tête HTTPReporting-Endpoints.
Spécifications
| Spécification |
|---|
| HTML # coep |
Compatibilité des navigateurs
Voir aussi
- L'en-tête
Cross-Origin-Embedder-Policy - L'en-tête
Cross-Origin-Opener-Policy - Les propriétés API
Window.crossOriginIsolatedetWorkerGlobalScope.crossOriginIsolated - L'interface
ReportingObserver - L'interface
COEPViolationReport - L'API Reporting
- La politique Cross Origin Opener (angl.) dans Why you need "cross-origin isolated" for powerful features sur web.dev (2020)
- COOP et COEP expliqués : Artur Janc, Charlie Reis, Anne van Kesteren (angl.) (2020)