Rendre votre site Web « isolé multi-origine » à l'aide de COOP et COEP

Utilisez COOP et COEP pour configurer un environnement isolé multi-origine et activer des fonctionnalités puissantes telles que SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et un minuteur haute résolution avec une meilleure précision.

Eiji Kitamura

Publié le 13 avril 2020, dernière mise à jour le 21 juin 2022

Attention SharedArrayBuffer sur Chrome pour ordinateur nécessite une isolation multi-origine à partir de Chrome 92. Pour en savoir plus, consultez Mises à jour de SharedArrayBuffer.

Ce document explique comment utiliser ces COOP et COEP. Pour en savoir plus sur l'importance de cette fonctionnalité, consultez Rendre votre site Web "isolé multi-origine" à l'aide de COOP et COEP.

Certaines API Web augmentent le risque d'attaques par canal auxiliaire, comme Spectre. Pour atténuer ce risque, les navigateurs proposent un environnement isolé basé sur l'activation, appelé "isolé multi-origine". Avec un état isolé multi-origine, la page Web pourra utiliser des fonctionnalités privilégiées, y compris les suivantes :

Fonctionnalités disponibles avec l'état isolé multi-origine.

API	Description
SharedArrayBuffer	Obligatoire pour les threads WebAssembly. Disponible à partir d'Android Chrome 88. La version classique est activée par défaut à l' aide de l' isolation de sites, mais elle nécessitera l'état isolé multi-origine et sera désactivée par défaut dans Chrome 92.
performance.measureUserAgentSpecificMemory()	Disponible à partir de Chrome 89.
performance.now(), performance.timeOrigin	Disponible dans de nombreux navigateurs, avec une résolution limitée à 100 microsecondes ou plus. Avec l'isolation multi-origine, la résolution peut être de 5 microsecondes ou plus.

L'état isolé multi-origine empêche également les modifications de document.domain. (La possibilité de modifier document.domain permet la communication entre des documents du même site et a été considérée comme une faille dans la règle SOP.)

Pour activer un état isolé multi-origine, vous devez envoyer les en-têtes HTTP suivants sur le document principal :

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

Ces en-têtes indiquent au navigateur de bloquer le chargement des ressources ou des iFrames qui n'ont pas choisi d'être chargés par des documents interorigines, et empêchent les fenêtres interorigines d'interagir directement avec votre document. Cela signifie également que ces ressources chargées interorigines nécessitent une activation.

Vous pouvez déterminer si une page Web est dans un état isolé multi-origine en examinant self.crossOriginIsolated.

Remarque : Ce document s'adresse aux personnes qui souhaitent préparer leurs sites Web à l'utilisation de SharedArrayBuffer, des threads WebAssembly, performance.measureUserAgentSpecificMemory() ou d'un minuteur haute résolution avec une meilleure précision de manière plus robuste sur toutes les plates-formes de navigateur.

Glossaire

Ce document utilise de nombreux termes aux noms et abréviations similaires. Pour plus de clarté, nous avons créé un mini-glossaire :

• COEP : Règlement de l'intégrateur multi-origine
• COOP : Règle d'ouverture multi-origine
• CORP : Règle de ressource multi-origine
• CORS : Partage des ressources entre origines multiples
• CORB : Blocage de la lecture multi-origine

Rendre votre site Web isolé multi-origine

**Conseil** : Découvrez les étapes pratiques pour activer l'isolation multi-origine.

1. Définissez Cross-Origin-Opener-Policy: same-origin sur le document de premier niveau

En activant COOP: same-origin sur un document de premier niveau, les fenêtres ayant la même origine et les fenêtres ouvertes à partir du document disposent d'un groupe de contexte de navigation distinct, sauf si elles ont la même origine avec le même paramètre COOP. L'isolation est donc appliquée aux fenêtres ouvertes et la communication mutuelle entre les deux fenêtres est désactivée.

Un groupe de contexte de navigation est un ensemble de fenêtres qui peuvent se référencer mutuellement. Par exemple, un document de premier niveau et ses documents enfants intégrés à l'aide de <iframe>. Si un site Web (https://a.example) ouvre une boîte de dialogue (https://b.example), la fenêtre d'ouverture et la boîte de dialogue partagent le même contexte de navigation. Elles ont donc accès l'une à l'autre avec des API DOM telles que window.opener.

Vous pouvez vérifier si l'ouvreur de fenêtre et son destinataire se trouvent dans des groupes de contexte de navigation distincts à partir des outils de développement.

2. Activez CORP ou CORS sur les ressources

Assurez-vous que toutes les ressources de la page sont chargées avec des en-têtes HTTP CORP ou CORS. Cette étape est requise pour l'étape 4, qui consiste à activer COEP.

Voici ce que vous devez faire, en fonction de la nature de la ressource :

• Si la ressource ne doit être chargée qu'à partir de la même origine, définissez l'en-tête Cross-Origin-Resource-Policy: same-origin.
• Si la ressource ne doit être chargée qu'à partir du même site, mais d'une origine différente , définissez l'Cross-Origin-Resource-Policy: same-site en-tête.
• Si la ressource est chargée à partir d'une ou de plusieurs origines que vous contrôlez, définissez l' Cross-Origin-Resource-Policy: cross-origin si possible.
• Pour les ressources multi-origine que vous ne contrôlez pas :
  • Utilisez l'attribut crossorigin dans la balise HTML de chargement si la ressource est diffusée avec CORS. (Par exemple, <img src="***" crossorigin>.)
  • Demandez au propriétaire de la ressource de prendre en charge CORS ou CORP.
• Pour les iFrames, suivez les mêmes principes et définissez Cross-Origin-Resource-Policy: cross-origin (ou same-site, same-origin selon le contexte).
• Les scripts chargés avec un WebWorker doivent être diffusés à partir de la même origine. Vous n'avez donc pas besoin d'en-têtes CORP ou CORS.
• Pour un document ou un Worker diffusé avec COEP: require-corp, les sous-ressources interorigines chargées sans CORS doivent définir l'en-tête Cross-Origin-Resource-Policy: cross-origin pour choisir d'être intégrées. Par exemple, cela s'applique à <script>, importScripts, <link>, <video>, <iframe>, etc.

Terme clé : Les sites _du même site_ sont des sites Web qui ont le même schéma et le même eTLD+1. Les sites de la même origine sont des sites Web qui ont la même combinaison de schéma, de nom d'hôte et de port. En savoir plus sur la différence entre les sites du même site et de la même origine.

Isolation dans les iFrames

Vous pouvez activer l'isolation multi-origine sur un document intégré dans un iFrame en appliquant allow="cross-origin-isolated" la règle d'autorisation à la <iframe> balise et en respectant ces conditions. L'ensemble de la chaîne de documents, y compris les cadres parents et enfants, doit également être isolé multi-origine.

3. Utilisez l'en-tête HTTP COEP Report-Only pour évaluer les ressources intégrées

Avant d'activer complètement COEP, vous pouvez effectuer un test à blanc à l'aide de l'en-tête Cross-Origin-Embedder-Policy-Report-Only pour vérifier si la règle fonctionne réellement. Vous recevrez des rapports sans bloquer le contenu intégré.

Appliquez cette opération de manière récursive à tous les documents, y compris le document de premier niveau, les iFrames et les scripts de worker. Pour en savoir plus sur l'en-tête HTTP Report-Only, consultez Observer les problèmes à l'aide de l'API Reporting.

4. Activez COEP

Cette étape ne peut être effectuée qu'une fois que vous vous êtes assuré que CORP ou CORS est activé pour les ressources.

Une fois que vous avez confirmé que tout fonctionne et que toutes les ressources peuvent être chargées correctement, remplacez l'en-tête Cross-Origin-Embedder-Policy-Report-Only par l'en-tête Cross-Origin-Embedder-Policy avec la même valeur pour tous les documents, y compris ceux qui sont intégrés avec des iFrames et des scripts de worker.

Remarque : Squoosh, une PWA d'optimisation des images, utilise COOP / COEP pour accéder aux threads Wasm (et au Shared Array Buffer) sur Android Chrome.

Attention : Nous étudions comment déployer Cross-Origin-Resource-Policy à grande échelle, car l'isolation multi-origine nécessite que toutes les sous-ressources soient explicitement activées. Une option est le mode sans identifiants COEP, qui permet de charger des ressources sans l'en-tête CORP en supprimant tous leurs identifiants. Le mode sans identifiants est disponible à partir de Chrome 96 et dans Edge, mais n'est pas encore compatible avec d'autres navigateurs.

Déterminez si l'isolation a réussi

La propriété self.crossOriginIsolated renvoie true lorsque la page Web est dans un état isolé multi-origine et que toutes les ressources et fenêtres sont isolées dans le même groupe de contexte de navigation. Vous pouvez utiliser cette API pour déterminer si vous avez correctement isolé le groupe de contexte de navigation et accédé à des fonctionnalités telles que performance.measureUserAgentSpecificMemory().

Débogage de problèmes

Vous pouvez rencontrer des problèmes avec COOP et COEP. Vous pouvez utiliser les outils pour les développeurs du navigateur ou l'API Reporting pour effectuer le débogage.

Déboguer avec les Outils pour les développeurs Chrome

Pour les ressources affichées à l'écran, telles que les images, il est assez facile de détecter les problèmes COEP, car la requête est bloquée et la page doit indiquer qu'une image est manquante. Toutefois, pour les ressources qui n'ont pas nécessairement d'impact visuel, comme les scripts ou les styles, les problèmes COEP peuvent passer inaperçus. Dans ce cas, utilisez le panneau Réseau des outils de développement.

En cas de problème avec COEP, vous devriez voir (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) dans la colonne Status (État).

Vous pouvez ensuite cliquer sur l'entrée pour afficher plus de détails.

Vous pouvez également déterminer l'état des iFrames et des boîtes de dialogue via le panneau Application. Accédez à la section "Frames" (Cadres) sur la gauche et développez "top" (en haut) pour afficher la structure des ressources.

Vous pouvez vérifier l'état de l'iFrame, par exemple la disponibilité de SharedArrayBuffer, etc.

Vous pouvez également vérifier l'état des boîtes de dialogue, par exemple si elles sont isolées multi-origine.

Observer les problèmes à l'aide de l'API Reporting

L'API Reporting est un autre mécanisme qui vous permet de détecter divers problèmes. Vous pouvez configurer l'API Reporting pour demander au navigateur de vos utilisateurs d'envoyer un rapport chaque fois que COEP bloque le chargement d'une ressource ou que COOP isole une boîte de dialogue. Chrome est compatible avec l'API Reporting depuis la version 69 pour diverses utilisations, y compris COEP et COOP.

Remarque : Utilisez-vous déjà l'API Reporting avec l'en-tête Report-To ? Chrome passe à une nouvelle version de l'API Reporting, qui remplace Report-To par Reporting-Endpoints. Envisagez de migrer vers la nouvelle version. Pour en savoir plus, consultez Migrer vers l'API Reporting v1.

Découvrez comment configurer l'API Reporting et configurer un serveur pour recevoir des rapports.

Exemple de rapport COEP

Voici un exemple de charge utile de rapport COEP lorsqu'une ressource interorigine est bloquée :

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]

Attention : blocked-url n'existe que pour la rétrocompatibilité et sera supprimé.

Exemple de rapport COOP

Voici un exemple de charge utile de rapport COOP lorsqu'une boîte de dialogue est ouverte de manière isolée :

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

Lorsque différents groupes de contexte de navigation tentent d'accéder les uns aux autres (uniquement en mode "report-only"), COOP envoie également un rapport. Par exemple, un rapport lorsque postMessage() est tenté se présente comme suit :

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

Points à retenir

Utilisez une combinaison d'en-têtes HTTP COOP et COEP pour activer un état isolé multi-origine spécial pour une page Web. Vous pouvez examiner self.crossOriginIsolated pour déterminer si une page Web est dans un état isolé multi-origine.

Nous mettrons à jour cet article à mesure que de nouvelles fonctionnalités seront disponibles pour cet état isolé multi-origine et que d'autres améliorations seront apportées aux outils de développement concernant COOP et COEP.

Ressources

• Pourquoi vous avez besoin d'un état "isolé multi-origine" pour des fonctionnalités puissantes
• Guide pour activer l'isolation multi-origine
• Surveiller l'utilisation totale de la mémoire de votre page Web avec measureUserAgentSpecificMemory()

Changements dans la documentation

• 21 juin 2022 : les scripts de worker doivent également être traités avec soin lorsque l'isolation multi-origine est activée. Ajout de quelques explications.
• 5 août 2021 : l'API JS Self-Profiling a été mentionnée comme l'une des API qui nécessitent une isolation multi-origine, mais suite à une modification récente de la direction, elle a été supprimée.
• 6 mai 2021 : en fonction des commentaires et des problèmes signalés, nous avons décidé d'ajuster le calendrier d'utilisation de SharedArrayBuffer dans les sites non isolés multi-origine pour qu'il soit limité dans Chrome M92.
• 16 avril 2021 : ajout de notes sur le mode sans identifiants COEP et sur COOP same-origin-allow-popups comme condition assouplie pour l'isolation multi-origine.
• 5 mars 2021 : suppression des limites pour SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et les fonctionnalités de débogage, qui sont désormais entièrement activées dans Chrome 89. Ajout des fonctionnalités à venir, performance.now() et performance.timeOrigin, qui auront une plus grande précision.
• 19 février 2021 : ajout d'une note sur la règle de fonctionnalité allow="cross-origin-isolated" et la fonctionnalité de débogage dans les outils de développement.
• 15 octobre 2020 : self.crossOriginIsolated est disponible à partir de Chrome 87. En conséquence, document.domain est immuable lorsque self.crossOriginIsolated renvoie true. performance.measureUserAgentSpecificMemory() met fin à son essai Origin Trial et est activé par défaut dans Chrome 89. Le Shared Array Buffer sur Android Chrome sera disponible à partir de Chrome 88.