isoler votre site Web multi-origine à l'aide de COOP et COEP.

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

Eiji Kitamura

Actualités

  • 21 juin 2022 : les scripts Worker doivent également être traités avec soin lorsque l'isolation multi-origine est activée. Ajout d'explications.
  • 5 août 2021 : l'API JS Self-Profiling a été mentionnée comme l'une des API nécessitant l'isolation multi-origine, mais elle a été supprimée suite à un changement de direction récent.
  • 6 mai 2021 : En fonction des commentaires et des problèmes signalés, nous avons décidé de modifier le calendrier d'utilisation de SharedArrayBuffer dans les sites non isolés multi-origine, qui sera limité dans Chrome M92.
  • 16 avril 2021 : ajout de notes concernant un nouveau mode COEP sans identifiants et 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 prochaines fonctionnalités performance.now() et performance.timeOrigin, qui seront plus précises.
  • 19 février 2021 : ajout d'une note sur la fonctionnalité de débogage et la feature policy allow="cross-origin-isolated" dans les outils pour les développeurs.
  • 15 octobre 2020 : self.crossOriginIsolated est disponible à partir de Chrome 87. Par conséquent, 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. Shared Array Buffer sur Android Chrome sera disponible à partir de Chrome 88.

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é "isolation multi-origine". Dans un état isolé d'origine croisée, la page Web pourra utiliser des fonctionnalités privilégiées, y compris :

API Description
SharedArrayBuffer Obligatoire pour les threads WebAssembly. Cette fonctionnalité est disponible à partir de Chrome 88 sur Android. La version pour ordinateur est actuellement activée par défaut grâce à l' isolation de sites, mais elle nécessitera l'état d'isolation multi-origine et sera désactivée par défaut dans Chrome 92.
performance.measureUserAgentSpecificMemory() Disponible à partir de Chrome 89.
performance.now(), performance.timeOrigin Actuellement 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.
Fonctionnalités qui seront disponibles avec l'état isolé multi-origine.

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

Pour activer l'état d'isolation 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 été activés pour être chargés par des documents d'origine croisée, et empêchent les fenêtres d'origine croisée d'interagir directement avec votre document. Cela signifie également que les ressources chargées en mode multi-origine nécessitent une activation.

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

Cet article vous explique comment utiliser ces nouveaux en-têtes. Dans un article de suivi, je fournirai plus d'informations générales et de contexte.

Déployer COOP et COEP pour isoler votre site Web des origines croisées

Intégrer COOP et COEP

1. Définissez l'en-tête Cross-Origin-Opener-Policy: same-origin sur le document de premier niveau.

Si vous activez COOP: same-origin sur un document de premier niveau, les fenêtres ayant la même origine et celles ouvertes à partir du document auront 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 contextes 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 via <iframe>. Si un site Web (https://a.example) ouvre une fenêtre pop-up (https://b.example), la fenêtre d'origine et la fenêtre pop-up partagent le même contexte de navigation. Elles ont donc accès l'une à l'autre via les API DOM telles que window.opener.

Groupe de contexte de navigation

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

2. S'assurer que CORP ou CORS sont activés pour 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 que depuis la même origine, définissez l'en-tête Cross-Origin-Resource-Policy: same-origin.
  • Si la ressource est censée être chargée uniquement à partir du même site, mais avec une origine croisée, définissez l'en-tête Cross-Origin-Resource-Policy: same-site.
  • Si la ressource est chargée à partir d'une ou plusieurs origines croisées que vous contrôlez, définissez l'en-tête Cross-Origin-Resource-Policy: cross-origin si possible.
  • Pour les ressources d'origine croisée sur lesquelles vous n'avez aucun contrôle :
    • 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 que ci-dessus 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 ni CORS.
  • Pour un document ou un worker diffusé avec COEP: require-corp, les sous-ressources d'origine croisée chargées sans CORS doivent définir l'en-tête Cross-Origin-Resource-Policy: cross-origin pour accepter d'être intégrées. Par exemple, cela s'applique à <script>, importScripts, <link>, <video>, <iframe>, etc.

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

Avant d'activer complètement COEP, vous pouvez effectuer une simulation à 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 règle 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. Activer COEP

Une fois que vous avez vérifié 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 via des iFrames et des scripts de worker.

Déterminer si l'isolation a réussi avec self.crossOriginIsolated

La propriété self.crossOriginIsolated renvoie true lorsque la page Web est dans un état d'isolation cross-origin 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 contextes de navigation et si vous avez accès à des fonctionnalités puissantes telles que performance.measureUserAgentSpecificMemory().

Déboguer les problèmes à l'aide des outils pour les développeurs Chrome

Pour les ressources affichées à l'écran, comme les images, il est assez facile de détecter les problèmes COEP, car la requête sera bloquée et la page indiquera 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 liés à COEP peuvent passer inaperçus. Pour cela, utilisez le panneau "Réseau" des outils pour les développeurs. En cas de problème avec COEP, (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) devrait s'afficher dans la colonne État.

Problèmes COEP dans la colonne &quot;État&quot; du panneau &quot;Réseau&quot;.

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

Les détails du problème COEP sont affichés dans l&#39;onglet &quot;En-têtes&quot; après avoir cliqué sur une ressource réseau dans le panneau &quot;Réseau&quot;.

Vous pouvez également déterminer l'état des iFrames et des fenêtres pop-up dans 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, comme la disponibilité de SharedArrayBuffer, etc.

Inspecteur d&#39;iFrame des outils pour les développeurs Chrome

Vous pouvez également vérifier l'état des fenêtres pop-up, par exemple si elles sont isolées d'origine croisée.

Inspecteur de fenêtres pop-up des Outils pour les développeurs Chrome

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

L'API Reporting est un autre mécanisme qui vous permet de détecter différents 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 fenêtre pop-up. Chrome est compatible avec l'API Reporting depuis la version 69 pour diverses utilisations, y compris COEP et COOP.

Pour apprendre à configurer l'API Reporting et à configurer un serveur pour recevoir des rapports, consultez Utiliser l'API Reporting.

Exemple de rapport COEP

Voici un exemple de charge utile de rapport COEP lorsqu'une ressource d'origine croisée 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"
}]

Exemple de rapport COOP

Voici un exemple de charge utile de rapport COOP lorsqu'une fenêtre pop-up isolée est ouverte :

[{
  "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 contextes de navigation tentent d'accéder les uns aux autres (uniquement en mode "rapport uniquement"), COOP envoie également un rapport. Par exemple, un rapport lorsque postMessage() est tenté se présenterait 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"
}]

Conclusion

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

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

Ressources