Cette page a été traduite par l'API Cloud Translation.

Guide pour activer l'isolation multi-origine

L'isolation multi-origine permet à une page Web d'utiliser des fonctionnalités puissantes telles que SharedArrayBuffer. Cet article explique comment activer l'isolation inter-origine sur votre site Web.

Eiji Kitamura

Ce guide vous explique comment activer l'isolation inter-origine. L'isolation inter-origine est requise si vous souhaitez utiliser SharedArrayBuffer, performance.measureUserAgentSpecificMemory() ou un minuteur haute résolution avec une meilleure précision.

Si vous avez l'intention d'activer l'isolation multi-origine, évaluez l'impact que cela aura sur les autres ressources multi-origines de votre site Web, comme les emplacements d'annonces.

Déterminer à quels endroits de votre site Web SharedArrayBuffer est utilisé

À partir de Chrome 92, les fonctionnalités qui utilisent SharedArrayBuffer ne fonctionneront plus sans isolation multi-origine. Si vous avez accédé à cette page en raison d'un message d'abandon de SharedArrayBuffer, il est probable que votre site Web ou l'une des ressources qui y sont intégrées utilise SharedArrayBuffer. Pour vous assurer que rien ne sera endommagé sur votre site Web en raison de l'abandon, commencez par identifier les endroits où il est utilisé.

Si vous ne savez pas où un SharedArrayBuffer est utilisé sur votre site, il existe deux façons de le savoir:

À l'aide des outils pour les développeurs Chrome
(Utilisateurs avancés) Utiliser les rapports d'abandon

Si vous savez déjà où vous utilisez SharedArrayBuffer, passez à la section Analyser l'impact de l'isolation inter-origine.

À l'aide des outils pour les développeurs Chrome

Les Outils pour les développeurs Chrome permettent aux développeurs d'inspecter des sites Web.

Ouvrez les outils pour les développeurs Chrome sur la page que vous pensez utiliser SharedArrayBuffer.
Sélectionnez le panneau Console.

Si la page utilise SharedArrayBuffer, le message suivant s'affiche :

[Deprecation] SharedArrayBuffer will require cross-origin isolation as of M92, around May 2021. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for more details. common-bundle.js:535

Le nom du fichier et le numéro de ligne à la fin du message (par exemple, common-bundle.js:535) indiquent d'où provient le SharedArrayBuffer. S'il s'agit d'une bibliothèque tierce, contactez le développeur pour résoudre le problème. Si elle est implémentée dans votre site Web, suivez le guide ci-dessous pour activer l'isolation inter-origine.

Avertissement dans la console des outils de développement lorsque SharedArrayBuffer est utilisé sans isolation multi-origine — avertissement dans la console des outils pour les développeurs lorsque SharedArrayBuffer est utilisé sans isolation multi-origine.

(Utilisateurs avancés) Utiliser les rapports d'abandon

Certains navigateurs disposent d'une fonctionnalité de création de rapports sur l'abandon des API vers un point de terminaison spécifié.

Configurez un serveur de rapports d'abandon et obtenez l'URL de création de rapports. Pour ce faire, vous pouvez utiliser un service public ou en créer un vous-même.
À l'aide de l'URL, définissez l'en-tête HTTP suivant sur les pages qui diffusent potentiellement SharedArrayBuffer.
```
Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"THE_DEPRECATION_ENDPOINT_URL"}]}
```
Une fois que l'en-tête commence à se propager, le point de terminaison auquel vous vous êtes inscrit doit commencer à collecter des rapports d'abandon.

Pour voir un exemple d'implémentation, consultez https://cross-origin-isolation.glitch.me.

Analyser l'impact de l'isolation multi-origine

N'est-il pas préférable d'évaluer l'impact de l'activation de l'isolation inter-origines sur votre site sans rien casser ? C'est exactement ce que vous permettent les en-têtes HTTP Cross-Origin-Opener-Policy-Report-Only et Cross-Origin-Embedder-Policy-Report-Only.

Définissez Cross-Origin-Opener-Policy-Report-Only: same-origin sur votre document de premier niveau. Comme son nom l'indique, cet en-tête n'envoie que des rapports sur l'impact que COOP: same-origin aurait sur votre site. Il ne désactive pas la communication avec les fenêtres pop-up.
Configurez la création de rapports et un serveur Web pour recevoir et enregistrer les rapports.
Définissez Cross-Origin-Embedder-Policy-Report-Only: require-corp sur votre document de premier niveau. Là encore, cet en-tête vous permet de voir l'impact de l'activation de COEP: require-corp sans que cela n'affecte le fonctionnement de votre site. Vous pouvez configurer cet en-tête pour envoyer des rapports au même serveur de rapports que celui que vous avez configuré à l'étape précédente.

Attention : L'activation de l'isolation multi-origine bloque le chargement des ressources multi-origines que vous n'activez pas explicitement et empêche votre document de niveau supérieur de communiquer avec les fenêtres pop-up. Nous avons étudié des moyens de déployer Cross-Origin-Resource-Policy à grande échelle, car l'isolation multi-origine nécessite que toutes les sous-ressources soient activées explicitement. Nous avons donc décidé d'aller dans la direction opposée : un nouveau mode "sans identifiants" COEP qui permet de charger des ressources sans l'en-tête CORP en supprimant tous leurs identifiants. Nous espérons que cela vous permettra de vous assurer que les sous-ressources envoient l'en-tête Cross-Origin-Resource-Policy. Bien que le mode credentialless soit disponible dans Chrome à partir de la version 96, il n'est pas encore compatible avec d'autres navigateurs. Il peut donc être difficile pour certains développeurs de déployer COOP ou COEP à ce stade. De plus, il est connu que l'en-tête Cross-Origin-Opener-Policy: same-origin interrompt les intégrations qui nécessitent des interactions de fenêtre multi-origine, telles que OAuth et les paiements. Pour atténuer ce problème, nous étudions la possibilité d'assouplir la condition afin d'activer l'isolation multi-origine pour Cross-Origin-Opener-Policy: same-origin-allow-popups. La communication avec la fenêtre ouverte automatiquement sera ainsi possible. Si vous souhaitez activer l'isolation multi-origine, mais que ces problèmes vous empêchent d'effectuer ces vérifications, nous vous recommandons de vous inscrire à une phase d'évaluation et d'attendre que les nouveaux modes soient disponibles. Nous ne prévoyons pas de mettre fin à la phase d'évaluation tant que ces nouveaux modes ne seront pas disponibles.

Limiter l'impact de l'isolation multi-origine

Une fois que vous avez déterminé les ressources concernées par l'isolation multi-origine, voici des consignes générales générales concernant l'activation de ces ressources multi-origines:

Pour les ressources multi-origines telles que les images, les scripts, les feuilles de style, les iFrames et autres, définissez l'en-tête Cross-Origin-Resource-Policy: cross-origin. Sur les ressources du même site, définissez l'en-tête Cross-Origin-Resource-Policy: same-site.
Pour les ressources pouvant être chargées à l'aide de CORS, assurez-vous qu'il est activé en définissant l'attribut crossorigin dans sa balise HTML (par exemple, <img src="example.jpg" crossorigin>). Pour une requête de récupération JavaScript, assurez-vous que request.mode est défini sur cors.
Si vous souhaitez utiliser des fonctionnalités puissantes telles que SharedArrayBuffer dans un iFrame chargé, ajoutez allow="cross-origin-isolated" à <iframe>.
Si les ressources inter-origines chargées dans des iFrames ou des scripts de worker impliquent une autre couche d'iFrames ou de scripts de worker, appliquez de manière récursive les étapes décrites dans cette section avant de continuer.
Une fois que vous avez confirmé que toutes les ressources inter-origines sont activées, définissez l'en-tête Cross-Origin-Embedder-Policy: require-corp sur les iFrames et les scripts de worker (cela est obligatoire, que la ressource soit de même origine ou inter-origine).
Assurez-vous qu'aucune fenêtre pop-up multi-origine ne nécessite de communication via postMessage(). Il n'est pas possible de les maintenir en service lorsque l'isolation inter-origine est activée. Vous pouvez déplacer la communication vers un autre document qui n'est pas isolé multi-origine ou utiliser une autre méthode de communication (par exemple, les requêtes HTTP).

Activer l'isolation inter-origine

Une fois que vous avez atténué l'impact grâce à l'isolation multi-origine, voici des consignes générales pour activer cette fonctionnalité :

Définissez l'en-tête Cross-Origin-Opener-Policy: same-origin sur votre document de premier niveau. Si vous avez défini Cross-Origin-Opener-Policy-Report-Only: same-origin, remplacez-le. Cela bloque la communication entre votre document de niveau supérieur et ses fenêtres pop-up.
Définissez l'en-tête Cross-Origin-Embedder-Policy: require-corp sur votre document de premier niveau. Si vous avez défini Cross-Origin-Embedder-Policy-Report-Only: require-corp, remplacez-le. Cela bloquera le chargement des ressources multi-origines qui ne sont pas activées.
Vérifiez que self.crossOriginIsolated renvoie true dans la console pour vérifier que votre page est isolée entre les origines.

L'activation de l'isolation inter-origines sur un serveur local peut s'avérer difficile, car les serveurs simples ne permettent pas d'envoyer d'en-têtes. Vous pouvez lancer Chrome avec un indicateur de ligne de commande --enable-features=SharedArrayBuffer pour activer SharedArrayBuffer sans activer l'isolation inter-origine. Découvrez comment exécuter Chrome avec un indicateur de ligne de commande sur les plates-formes respectives.