COOP et COEP expliqués, l'isolation cross-origin

Si vous avez tenté d'activer SharedArrayBuffer, d'utiliser des timers haute résolution ou d'exécuter certaines charges WebAssembly, vous avez rencontré un mur appelé isolation cross-origin, et les deux headers qui l'ouvrent : COOP et COEP. On les rencontre presque toujours ensemble, car l'un sans l'autre ne sert à rien. Cet article explique ce que fait chaque header, pourquoi ils ne fonctionnent qu'ensemble, et comment les activer sans casser le contenu tiers déjà présent sur votre page.

Ce que fait chaque header

Cross-Origin-Opener-Policy (COOP) contrôle la façon dont votre page partage un groupe de contextes de navigation avec les fenêtres qui l'ouvrent ou qu'elle ouvre. Avec same-origin, le navigateur coupe la référence window.opener entre votre page et les fenêtres cross-origin, de sorte qu'un popup ou un opener sur une autre origine ne peut plus atteindre l'objet window de votre page. Cela bloque une classe d'attaques de scripting inter-fenêtres et de canaux auxiliaires. Référence : la page de la politique COOP.

Cross-Origin-Embedder-Policy (COEP) travaille sur l'autre axe : il exige que chaque ressource cross-origin que votre page charge accepte explicitement d'être intégrée, soit via un header Cross-Origin-Resource-Policy, soit via CORS (comment CORP et COEP s'articulent). Avec require-corp, une image ou un script cross-origin qui ne donne pas son accord est bloqué. Cela empêche une page d'aspirer silencieusement des données cross-origin dans son propre processus. Référence : la page de la politique COEP.

Pourquoi les deux sont nécessaires

L'isolation cross-origin est un état unique du navigateur qui commande l'accès à un ensemble de fonctionnalités sensibles (SharedArrayBuffer, timers précis, entre autres). Le navigateur ne l'accorde que lorsqu'un document ferme les deux frontières à la fois : la frontière des fenêtres avec COOP, et la frontière des ressources avec COEP.

Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Embedder-Policy: require-corp

Vous pouvez confirmer le résultat à l'exécution avec self.crossOriginIsolated, qui renvoie true uniquement quand les deux headers sont en vigueur. Envoyez l'un sans l'autre et vous n'obtenez ni isolation ni fonctionnalités. C'est pour cette raison que poser COOP seul, ou COEP seul, en attendant que SharedArrayBuffer se mette à marcher, est une impasse courante.

La partie difficile, c'est COEP

COOP est généralement facile : la plupart des pages ne dépendent pas d'un accès window.opener cross-origin, donc same-origin fonctionne tout de suite. C'est avec COEP que les déploiements calent. Activer require-corp bloque chaque ressource cross-origin qui n'envoie pas de CORP ou ne passe pas CORS, et sur une page avec une douzaine de tiers (polices, analytics, intégrations, tags publicitaires), cela peut casser beaucoup de choses d'un coup. Le correctif n'est pas de deviner lesquels coopèrent, c'est de mesurer.

Déployez-le en report-only d'abord

Les deux headers ont une variante Report-Only qui évalue la politique et signale ce qui casserait, sans l'imposer réellement. Pointez-la vers un endpoint et collectez les reports avant de vous engager, pour que l'isolation ne mette pas hors service une iframe de paiement en production.

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

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

Le navigateur envoie alors un report coep pour chaque ressource qui serait bloquée, vous donnant la liste exacte à corriger ou remplacer avant d'imposer. La même approche Report-Only s'applique à COOP et à ses reports coop.

Note sur le support navigateur

Les valeurs de base de COOP et COEP sont standard et largement prises en charge. La valeur COEP credentialless n'est pas prise en charge dans Safari, et la livraison report-to pour ces politiques est réservée à Chromium, donc traitez le volet reporting comme une couverture partielle.

Collectez les reports de déploiement

L'étape report-only ne vaut que par votre capacité à voir les reports. CentralCSP collecte les reports COOP et COEP aux côtés du reste de vos reports de navigateur, pour que vous puissiez mesurer l'impact de l'isolation sur votre trafic réel, et pas seulement sur les tiers qui se chargent sur votre machine, puis imposer une fois que le flux de reports s'est tari.

Les ressources bloquées par COEP, chaque URL cross-origin qui n'a pas donné son accord, avec son origine de document et sa disposition

Étapes suivantes

Mettez d'abord en place le reporting : comment mettre en place la Reporting API.
Lisez les références COOP et COEP.
Retirez les headers que ceux-ci remplacent : security headers hérités à abandonner.

Déployez l'isolation cross-origin en toute sécurité.

COOP et COEP expliqués, isolation cross-origin en pratique