Isolation inter-origines : en-têtes et SharedArrayBuffer

L’isolation inter-origines est un état de sécurité du navigateur qui résulte d’un ensemble compatible de politiques de réponse et de relations entre documents. Elle peut activer des fonctions Web telles que SharedArrayBuffer dans les navigateurs qui les prennent en charge, mais elle ne rend pas toutes les ressources d’autres origines utilisables. Un déploiement de premier niveau combine généralement Cross-Origin-Opener-Policy: same-origin (COOP) avec une valeur de Cross-Origin-Embedder-Policy (COEP), par exemple require-corp ou, si le navigateur et le cas d’usage le permettent, credentialless. Le document peut ensuite lire window.crossOriginIsolated afin de confirmer l’état obtenu dans le navigateur.

La décision de déploiement ne se limite pas à « ajouter deux en-têtes ». COOP modifie la relation de la page avec les fenêtres ouvertes depuis d’autres origines ; COEP modifie les conditions de chargement des ressources intégrées provenant d’autres origines. Ces changements peuvent toucher l’authentification par fenêtre contextuelle, les paiements, l’analytique, les médias, les polices, les cadres et les scripts de fournisseurs. Avant d’activer du code qui dépend de fonctions réservées à l’isolation, inventorie ces dépendances, vérifie leurs réponses réelles et déploie la politique progressivement, avec une solution de repli et un plan de retour arrière explicites. C’est un choix d’architecture qui a un coût de compatibilité.

Ce que change l’isolation inter-origines

Le modèle d’isolation inter-origines de WHATWG HTML décrit un état du navigateur, et non un tunnel réseau ou une propriété qu’un script peut définir. La page choisit une relation plus stricte avec les autres contextes de navigation et les ressources intégrées. Si le navigateur accepte la politique applicable et les relations entre documents requises, il expose l’état qui en résulte par crossOriginIsolated. C’est cette valeur d’exécution qu’il faut consigner : la présence d’un en-tête dans la réponse du serveur ne prouve pas à elle seule que le document chargé est isolé.

Une origine différente peut avoir un autre schéma, hôte ou port. Un sous-domaine appartenant à la même organisation peut donc être d’une autre origine. Les frontières d’origine ne sont pas les frontières de site ; un nom d’hôte de CDN, un domaine d’assets ou un cadre hébergé par un client peuvent modifier la politique applicable. Une ressource qui fonctionne en développement local peut avoir une origine et une configuration de réponse différentes en production.

L’isolation est souvent évoquée avec SharedArrayBuffer, mais ce n’est qu’un cas d’usage. Certaines applications ont besoin de cette fonction pour des bibliothèques ou des capacités d’exécution prises en charge. Les conditions précises de disponibilité varient selon le navigateur et la version de plateforme. Un contexte sécurisé et un document isolé sont des prérequis courants, mais ne garantissent pas que chaque environnement expose chaque fonction. Consulte les données de compatibilité de l’API concernée et teste le document déployé. Ne déduis pas la disponibilité d’un agent utilisateur ni de la seule présence d’un en-tête.

window.crossOriginIsolated indique si le navigateur considère l’environnement global courant comme isolé. Cette valeur n’explique pas quel en-tête ou quelle ressource intégrée a empêché l’isolation. Un diagnostic utile associe ce booléen à l’URL finale du document, aux en-têtes pertinents, à la version du navigateur et à un inventaire contrôlé des ressources. Limite le rapport aux faits de configuration ; il n’a besoin ni de données utilisateur ni d’attributs sans rapport du navigateur.

COOP et COEP ont des rôles distincts

COOP contrôle la relation d’un document avec les contextes de navigation de premier niveau, y compris les relations opener. Avec Cross-Origin-Opener-Policy: same-origin, la page est séparée des documents d’autres origines dans un groupe de contextes de navigation dans les cas concernés. Cela isole davantage les fenêtres, mais peut modifier les parcours qui utilisent window.opener, par exemple une fenêtre de connexion qui renvoie son résultat à la page d’origine. La référence COOP de MDN décrit les valeurs et leurs effets. Teste les parcours de connexion, de paiement et d’assistance avec fenêtre contextuelle au lieu de supposer que ces intégrations ne changent pas.

COEP contrôle le chargement des ressources d’autres origines intégrées par un document. Avec Cross-Origin-Embedder-Policy: require-corp, la ressource doit généralement être demandée par CORS et renvoyer une réponse CORS valide, ou être servie avec une réponse Cross-Origin-Resource-Policy (CORP) compatible. Une ressource auparavant chargée par une requête sans CORS peut être bloquée si elle n’autorise pas son intégration. Son propriétaire ou le CDN devra peut-être renvoyer Access-Control-Allow-Origin pour une requête CORS ou un en-tête Cross-Origin-Resource-Policy adapté à une ressource sans CORS admissible. Le bon en-tête dépend du type de ressource, des identifiants et de la frontière de partage prévue.

Le mode COEP credentialless peut assouplir l’exigence CORP pour certaines ressources sans CORS en les chargeant sans identifiants. Il modifie la requête : aucun cookie ni autre identifiant n’est envoyé pour ces appels. Avant de le choisir, vérifie sa prise en charge et son comportement détaillé dans la documentation actuelle du navigateur. Ce n’est pas un commutateur de compatibilité général et il ne convient pas aux ressources qui nécessitent une authentification. Le guide de l’isolation de MDN résume la combinaison des politiques et ses conséquences.

Ces rôles sont complémentaires. COOP seul n’impose pas les contrôles de ressources intégrées de COEP. Dans le déploiement isolé courant, COEP seul n’apporte pas non plus la séparation de premier niveau requise. L’état final dépend de l’ensemble des politiques et des relations entre documents, pas d’un réglage manuel. N’assouplis pas globalement la politique pour charger un script tiers : identifie la ressource, trouve son propriétaire et choisis CORS, CORP, un proxy approuvé ou une autre intégration correspondant à l’accès prévu.

Ressources intégrées et frontières d’origine

Avant d’appliquer COEP, inventorie toutes les ressources que la page peut intégrer ou demander : scripts, feuilles de style, polices, images, audio, vidéo, Workers, cadres imbriqués et ressources chargées par du code tiers. Classe chacune comme même origine, autre origine avec CORS, autre origine avec CORP ou intégration incapable de respecter la politique choisie. Inspecte les réponses réseau réelles en préproduction. L’URL ne révèle pas à elle seule si la réponse contient l’en-tête requis, si une redirection change l’origine ou si une requête avec identifiants reçoit une réponse CORS compatible.

Utilise un tableau de compatibilité qui attribue un responsable et une décision à chaque dépendance :

Cas de dépendance	Éléments à vérifier	Décision de déploiement
Ressource applicative de même origine	URL finale et état de la réponse	La conserver de même origine et vérifier les redirections
Ressource publique d’une autre origine	Mode CORS et Access-Control-Allow-Origin, ou réponse CORP adaptée	Définir la configuration avec le propriétaire et tester la réponse réelle
Requête inter-origines nécessitant des identifiants	Mode d’identifiants, origine autorisée exacte et en-têtes correspondants	Définir un contrat CORS explicite, sans le remplacer par credentialless
Ressource tierce qui ne peut pas autoriser son intégration	Responsable, finalité et caractère essentiel	La remplacer, la mandater via un proxy approuvé, la reporter ou conserver un repli sans isolation
Fenêtre contextuelle ou cadre d’une autre origine	Comportement d’opener, origine du cadre et relation des politiques	Tester le parcours utilisateur complet avec la politique cible

Un iframe d’une autre origine est un document indépendant avec sa propre origine et ses propres relations de politique. Ne suppose pas que la valeur crossOriginIsolated de la page supérieure décrit automatiquement chaque cadre enfant ni lui accorde toutes les capacités. Confirme les règles d’intégration et la délégation nécessaire pour la fonction concernée, puis vérifie l’état d’exécution du document enfant dans un fixture qui consigne l’origine attendue. Le cadre peut aussi nécessiter sa propre réponse compatible. Si tu ne contrôles pas ce cadre, coordonne-toi avec son propriétaire avant d’y dépendre d’une fonction réservée à l’isolation.

La politique doit respecter le principe du moindre privilège. N’autorise que les origines et types de ressources dont l’application a besoin, et empêche les intégrations tierces d’élargir l’accès sans visibilité. Une réponse CORS avec caractère générique peut convenir à une ressource publique sans identifiants, mais ne résout pas de manière universelle l’accès aux données authentifiées. Les valeurs CORP indiquent également qui peut intégrer une réponse ; choisis une valeur adaptée à la relation prévue plutôt que la plus large par défaut. Documente le responsable de chaque en-tête, en particulier lorsque la page, le CDN, le fournisseur d’identité et le service intégré sont gérés par des équipes différentes.

Fixture de déploiement déterministe

Ce fixture rend l’état d’isolation visible, le compare à une attente fournie par le cas de test et supprime le DOM temporaire même si une assertion ou un rapport échoue. Sers-le depuis la même origine et par le même chemin de réponse que l’application. Dans l’environnement candidat isolé, configure true ; pour un environnement témoin sans la politique complète, déclare l’attente séparément. Ne la déduis pas de la valeur testée.

async function checkIsolation(expected) {
  const host = document.createElement('section');
  const status = document.createElement('output');
  status.setAttribute('aria-live', 'polite');
  host.append(status);
  document.body.append(host);

  try {
    const isolated = window.crossOriginIsolated === true;
    const sharedMemoryAvailable = typeof SharedArrayBuffer === 'function';
    const passed = expected ? isolated && sharedMemoryAvailable : isolated === expected;
    status.textContent = `${passed ? 'PASS' : 'FAIL'}: isolated=${isolated}; SharedArrayBuffer=${sharedMemoryAvailable}`;

    console.assert(passed, status.textContent);
    if (expected) console.assert(sharedMemoryAvailable, 'Expected SharedArrayBuffer in this declared browser case');
    return { passed, isolated, sharedMemoryAvailable, visibleResult: status.textContent };
  } finally {
    host.remove();
  }
}

// La configuration de test déclare cette attente pour l’origine candidate.
await checkIsolation(true);

Le fixture rapporte deux faits distincts : l’état d’isolation du navigateur et la présence de SharedArrayBuffer dans cet environnement. Un cas navigateur pris en charge peut exiger les deux ; pour un navigateur hors du périmètre déclaré, on peut consigner l’absence de l’API et tester la solution de repli. Cette solution doit être vérifiée avec son propre résultat attendu et ne doit pas être présentée comme une isolation réussie. L’exemple n’alloue pas de mémoire partagée, ne lance aucun Worker et n’effectue aucune mesure. Il vérifie la configuration de réponse et l’éligibilité d’exécution sans ajouter une autre charge.

Pour vérifier la compatibilité des ressources, charge une ressource inter-origines représentative de chaque catégorie requise dans une petite page que tu contrôles. Attribue une URL stable à chaque ressource et vérifie un état de chargement ou d’échec visible. Garde un fixture par cas de politique afin que l’échec d’une police ne masque pas celui d’un script ou d’un cadre. N’inclus redirections et identifiants que si la dépendance de production les utilise. Au démontage, supprime les nœuds de test et ferme le contexte isolé ; ne modifie pas les données de production partagées.

Déploiement, suivi et retour arrière

Déploie par étapes. Commence par inventorier les dépendances inter-origines et identifier leurs responsables. Configure ensuite une origine de préproduction avec COOP et la valeur COEP choisie, puis lance le fixture et le parcours complet de l’application. Vérifie les en-têtes sur la réponse finale du document, et non uniquement sur le répartiteur de charge ou dans le fichier de configuration : redirections, règles CDN, service workers et routage par hôte peuvent modifier la réponse livrée. Confirme crossOriginIsolated après la navigation réelle, puis teste chaque ressource essentielle selon le mode de requête utilisé en production.

Avant un déploiement large, vérifie les parcours entre contextes de navigation : connexion par fenêtre contextuelle, transfert de paiement, cadres clients, widgets d’aide et toute intégration qui attend une référence opener. Teste également les versions de navigateur aux limites du périmètre pris en charge et un cas témoin utilisant la solution de repli. Conserve un rapport succinct indiquant l’URL finale, la version du navigateur, les valeurs COOP et COEP, l’état d’isolation, les ressources en échec, les origines des cadres et le résultat visible. N’y inscris ni secret, ni donnée de compte, ni information de profil sans rapport.

Le déploiement n’est prêt que si l’état isolé est observé là où il est attendu, si les ressources nécessaires se chargent selon la politique déclarée et si les personnes peuvent achever leur tâche principale quand la fonction est indisponible. Si une ressource fournisseur bloque la mise en production, conserve le repli ou remplace l’intégration ; n’affaiblis pas globalement la politique sans le documenter. Un échec d’isolation est un résultat de configuration à diagnostiquer, pas un motif pour modifier silencieusement les assertions.

Prépare le retour arrière avant de modifier les en-têtes de production. Garde disponibles la politique et la version antérieures. Si la nouvelle politique casse une intégration essentielle, rétablis ensemble la politique et le parcours applicatif précédemment fonctionnels, puis relance le même fixture pour vérifier l’état non isolé attendu et la solution de repli. Dans la version de retour arrière, supprime les chemins qui exigent une fonction réservée à l’isolation ou protège-les par une vérification d’exécution. Préserve la sécurité du transport et les autres en-têtes ; revenir en arrière ne justifie ni le HTTP ni l’effacement des preuves de test.

Ce que BotBrowser peut valider

BotBrowser prend en charge le QA autorisé d’applications dans des contextes de navigateur contrôlés : une équipe peut utiliser des contextes isolés pour exécuter un fixture qu’elle possède sur une version déclarée, vérifier l’état d’isolation à l’exécution et comparer les solutions de repli visibles sans reprendre l’état d’un parcours sans rapport. La documentation BotBrowser sur l’isolation multi-compte décrit des contextes distincts pour des sessions indépendantes. BotBrowser ne peut pas isoler un document entre origines, fournir les en-têtes COOP ou COEP, modifier les réponses CORS/CORP d’une ressource tierce, préserver un comportement de fenêtre contextuelle que la politique sépare intentionnellement, ni garantir la prise en charge de SharedArrayBuffer sur chaque plateforme. Le modèle d’isolation de WHATWG HTML et la configuration de déploiement du site restent déterminants. Utilise BotBrowser pour observer un parcours déclaré ; les équipes applicative et infrastructure restent responsables des contrats de ressources, des décisions de politique, de la compatibilité et du retour arrière.

Pour approfondir, consulte le guide de validation des versions de navigateur, le guide des contextes sécurisés et le guide de compatibilité des API de navigateur. Ils traitent des preuves de version, de l’éligibilité du contexte sécurisé et de la préparation des solutions de repli ; cette page porte sur les politiques de réponse et les ressources nécessaires à l’isolation inter-origines.

Consigne la décision de mise en production avec le responsable de chaque politique et contrat de ressource. Un retour arrière reste ainsi vérifiable : l’équipe peut distinguer un changement de réponse, une redirection, une règle CDN ou une dépendance intégrée. Limite le relevé aux réponses techniques et aux résultats visibles, puis répète les mêmes contrôles après chaque changement de politique.

Si une dépendance facultative échoue, documente l’alternative visible ; si elle est essentielle, suspends la mise en production jusqu’à ce que son responsable confirme une réponse compatible.

Sources

• WHATWG HTML : isolation inter-origines
• MDN : isolation inter-origines
• MDN : Cross-Origin-Opener-Policy
• MDN : Cross-Origin-Embedder-Policy
• MDN : SharedArrayBuffer
• BotBrowser : isolation multi-compte