Politique de même origine et isolation des sites

La politique de même origine est une règle du navigateur qui limite la manière dont un document ou un script peut lire et manipuler une autre origine. Une origine est la combinaison d'un schéma, d'un hôte et d'un port. Une page située à https://app.example.test est de même origine qu'une autre page située exactement à cette origine, mais toute modification du schéma, de l'hôte ou du port crée une origine différente. Cette politique délimite les données visibles par les scripts et les relations entre documents. Ce n'est ni un pare-feu réseau, ni un remplacement de l'autorisation côté serveur, ni une garantie qu'une réponse ne peut pas être envoyée sur le réseau.

L'isolation des sites est une architecture du navigateur et une défense de sécurité qui maintient, lorsque c'est possible, les documents de sites différents dans des espaces d'exécution séparés. Elle réduit l'impact d'une compromission du moteur de rendu et aide à contenir les données intersites, tandis que la politique de même origine continue de décider ce que les scripts peuvent lire. Ces notions se renforcent, mais répondent à des questions différentes. Une frontière entre processus ne valide pas l'appelant d'une API, et une restriction imposée aux scripts ne détermine pas la manière dont le navigateur répartit ses processus.

Cette distinction est importante lors du débogage. Une requête peut atteindre un serveur alors que JavaScript ne peut pas lire la réponse. Une iframe peut s'afficher alors que son parent ne peut pas inspecter le DOM enfant. Un navigateur peut placer des pages dans des espaces d'exécution séparés alors qu'une application accepte toujours une requête non autorisée qui modifie l'état. Consignez séparément l'observation du navigateur, la réponse du serveur et le résultat de l'application. Cette séparation préserve l'utilité d'un rapport de compatibilité sans laisser entendre qu'une propriété de sécurité non testée a été garantie.

Comment une origine est identifiée

Le modèle d'origine HTML de WHATWG définit une origine, pour les documents réseau ordinaires, à l'aide du schéma, de l'hôte et du port. https://shop.example.test:443 et https://shop.example.test utilisent normalement le même port effectif, tandis que http://shop.example.test est différent puisque le schéma diffère. https://cdn.example.test est différent puisque l'hôte diffère, même si la même organisation contrôle les deux hôtes. Un alias de développement, un nom d'hôte de préproduction ou un port non standard peuvent donc créer une frontière absente d'un fixture local.

Certains documents ont une origine opaque. Une iframe sandboxée sans jeton d'origine approprié, un document data: ou un document créé à partir d'une URL blob: peut avoir une origine qui n'est pas représentée par l'URL visible comme le serait celle d'un document réseau. Considérez la valeur d'origine fournie par le navigateur et la relation d'intégration documentée comme des entrées de test. N'inférez pas la confiance d'un nom d'hôte familier, d'un certificat ou du contrôle d'un domaine parent.

Les cookies, le stockage, les permissions, les service workers et de nombreuses API web utilisent des notions d'origine ou de site dont les règles sont liées, mais non identiques. Un cookie peut être limité à un domaine enregistrable, tandis que localStorage est limité à une origine. Un site peut contenir plusieurs origines, et une frame cross-origin peut tout de même être de même site selon la définition de site tenant compte du schéma. Lorsqu'un test modifie un hôte ou un protocole, définissez clairement les attentes pour chaque stockage d'état et consignez le location.origin final. Le guide du modèle de stockage du navigateur détaille davantage ces frontières de stockage.

La comparaison d'origine doit être une assertion explicite. Dans un fixture contrôlé, indiquez location.origin pour le document de premier niveau et pour chaque frame testée. Pour un message reçu d'une autre fenêtre, comparez event.origin à la valeur attendue avant d'utiliser les données du message. Ce contrôle prouve que le message provient de l'origine déclarée ; il ne prouve ni que l'application distante a autorisé l'action, ni que le contenu du message est sûr. Validez séparément le schéma des données et l'état courant du workflow au niveau de l'application.

Ce que permet la politique de même origine

La référence MDN sur la politique de même origine décrit la règle générale : les scripts d'une origine ont un accès limité aux documents et aux données d'une autre origine. Les scripts de même origine peuvent lire les nœuds DOM, la plupart des stockages de cette origine et les corps de réponse renvoyés à leur propre contexte JavaScript. Les scripts cross-origin peuvent souvent naviguer vers une fenêtre ou envoyer un formulaire, mais ils ne peuvent pas lire directement le DOM cible ni des octets de réponse arbitraires. Les autorisations exactes dépendent de l'API et de sa spécification ; classez donc l'opération au lieu de traiter « cross-origin » comme une réponse unique par oui ou non.

Les requêtes réseau cross-origin illustrent cette frontière. Le navigateur peut envoyer une requête et le serveur renvoyer un statut de succès, tandis que Fetch masque la réponse au script appelant si celle-ci ne respecte pas CORS. C'est pourquoi le panneau réseau peut afficher 200 en même temps qu'une erreur CORS au niveau de la page. CORS est un contrat de partage de réponses ; il n'accorde pas d'autorisation côté serveur et ne rend pas un endpoint digne de confiance. Consultez le guide des frontières CORS du navigateur lorsque la question porte sur la lisibilité d'une réponse plutôt que sur l'accès à un document.

Les relations entre fenêtres sont elles aussi limitées. Une page peut conserver une référence vers une popup cross-origin et utiliser un petit ensemble d'opérations sur la fenêtre, mais elle ne peut pas en inspecter les propriétés arbitraires. postMessage fournit un canal de communication explicite. Le récepteur doit vérifier event.origin, valider event.source lorsque c'est possible et analyser une structure de message contrainte. Lors de l'envoi, utilisez une origine cible concrète. Une cible générique peut convenir à un message volontairement public, mais ne doit pas servir pour des données de session ou de compte.

Les frames ont une origine de document indépendante. Un parent peut afficher une iframe cross-origin sans obtenir le droit d'en lire le DOM, et l'enfant ne peut pas lire le DOM du parent simplement parce qu'il est intégré. Une iframe de même origine partage néanmoins de nombreuses surfaces visibles par les scripts avec son parent ; une page compromise peut donc affecter les deux documents. Définissez une frontière claire de propriété et de confiance pour chaque frame. Si une frame a besoin d'une fonctionnalité du navigateur, évaluez séparément Permissions Policy, les exigences de contexte sécurisé et l'autorisation de l'utilisateur, sans les confondre avec la décision de même origine.

Contenu intégré et communication

Considérez une relation d'intégration comme un ensemble de contrats. Identifiez d'abord les origines du parent et de l'enfant après les redirections. Déterminez ensuite l'opération requise : rendu visuel, navigation, envoi de formulaire, échange de messages, lecture de réponse ou accès au DOM. Documentez enfin la règle du navigateur et le contrôle d'autorisation de l'application pour cette opération. Une page qui doit seulement afficher une image ne devrait pas recevoir les mêmes privilèges qu'une frame qui échange l'état d'un compte.

Relation ou opération	Preuve côté navigateur	Décision de l'application et ce que cela ne prouve pas
Accès au DOM de même origine	Les deux documents indiquent le même schéma, hôte et port	N'autoriser que du code contrôlé ; valider tout de même l'état et l'autorisation
Rendu d'une frame cross-origin	La frame se charge et indique son origine finale	Le rendu n'accorde ni accès au DOM ni accès à la réponse
Lecture d'une réponse cross-origin	Réponse CORS et mode de requête	La lisibilité n'est ni une autorisation serveur ni un succès métier
Message de fenêtre	event.origin, source et schéma attendus	N'accepter que le message déclaré ; ne pas faire confiance à l'origine seule
Documents isolés par site	Contexte visible du navigateur et build déclaré	La séparation des processus ne prouve pas la sécurité de l'application

Les redirections méritent une attention particulière. L'URL initiale d'un test peut ne pas être l'origine qui renvoie le document. Suivez la réponse finale et toute navigation de frame, puis affirmez l'origine finale. Un serveur peut également rediriger vers un autre site, ce qui modifie le comportement des cookies, du stockage et de CORS. Conservez les contrôles de redirection dans le fixture afin qu'une modification ultérieure de l'infrastructure ne déplace pas silencieusement un workflow de confiance au-delà d'une frontière.

N'utilisez pas document.domain comme stratégie d'intégration moderne. Cette propriété a historiquement assoupli l'accès entre sous-domaines, mais elle modifie le modèle d'origine effectif, entraîne des coûts de compatibilité et de sécurité et est progressivement dépréciée par les recommandations de la plateforme web. Préférez une messagerie explicite, une enveloppe d'application de même origine ou une API médiée par le serveur avec une authentification et une autorisation normales. Si une ancienne intégration en dépend encore, consignez cette dépendance et testez à la fois le chemin historique et son remplacement.

Ce que l'isolation des sites apporte

La présentation de l'isolation des sites de Chromium décrit l'isolation des sites comme une défense qui sépare les pages de sites différents dans les espaces d'exécution du navigateur. Dans plusieurs contextes de la plateforme web, un site est un regroupement plus large qu'une origine. Deux sous-domaines peuvent être des origines différentes tout en appartenant au même site, tandis que des pages ayant des domaines enregistrables différents appartiennent à des sites différents. L'ordonnancement du navigateur est un choix d'implémentation susceptible de varier selon la plateforme, la pression mémoire, la version du navigateur et les relations entre documents.

L'isolation des sites contribue à réduire la quantité de données intersites exposées si le moteur de rendu présente un problème de sécurité mémoire. Elle ne transforme pas chaque site en compte distinct du système d'exploitation et ne convertit pas une observation du navigateur en garantie applicative. Ne fondez pas l'autorisation produit sur une hypothèse concernant le comportement du moteur de rendu. Le serveur doit toujours authentifier la requête, vérifier le propriétaire de la ressource, appliquer les règles CSRF et de jetons pertinentes et valider les transitions d'état.

Les groupes de contextes de navigation et les relations d'ouverture peuvent influer sur l'isolation. Une popup ouverte entre sites peut ne pas partager le même groupe ou la même relation de script qu'une popup de même origine. COOP et COEP peuvent encore modifier les relations entre fenêtres et le chargement des ressources, comme l'explique le guide de l'isolation cross-origin. Ces en-têtes sont distincts de la politique de même origine. Une page peut être de même origine qu'un enfant tout en restant non isolée, ou être cross-origin avec un enfant qui se charge sous une politique compatible.

L'isolation des sites présente également des limites concernant les extensions, les surfaces privilégiées du navigateur, les service workers et les comportements propres à chaque navigateur. Un test doit préciser la famille du navigateur, la plage de versions, le système d'exploitation et les hypothèses de fonctionnalité. Évitez d'affirmer qu'un nombre de processus ou une allocation interne donnée est stable. L'assertion publique utile concerne le comportement de sécurité visible : un document cross-origin ne peut pas lire les données protégées et l'application rejette une modification d'état non autorisée. Ces résultats restent pertinents même lorsque le navigateur modifie son implémentation.

Un fixture de politique déterministe

Le fixture suivant utilise deux pages appartenant à la même équipe. La page de contrôle et la page candidate créent chacune une frame, tentent un échange de messages déclaré et affichent un résultat visible. Le résultat attendu vient de la configuration du test, et non de la réponse du navigateur. Le fixture ne lit pas de contenu privé de tiers, n'inspecte pas les processus internes et n'envoie pas d'identifiants.

async function checkOriginBoundary({ frameUrl, expectedOrigin, expectedMessage }) {
  const host = document.createElement('section');
  const status = document.createElement('output');
  status.setAttribute('aria-live', 'polite');
  const frame = document.createElement('iframe');
  frame.src = frameUrl;
  host.append(frame, status);
  document.body.append(host);

  const result = await new Promise(resolve => {
    const timer = setTimeout(() => resolve({ passed: false, reason: 'timeout' }), 3000);
    window.addEventListener('message', function onMessage(event) {
      if (event.source !== frame.contentWindow) return;
      clearTimeout(timer);
      window.removeEventListener('message', onMessage);
      const originMatches = event.origin === expectedOrigin;
      const messageMatches = event.data?.type === expectedMessage;
      resolve({ passed: originMatches && messageMatches, originMatches, messageMatches });
    });
  });

  try {
    status.textContent = result.passed
      ? 'PASS: declared origin and message'
      : `FAIL: ${result.reason || 'boundary mismatch'}`;
    console.assert(result.passed, status.textContent);
    return { ...result, visibleResult: status.textContent };
  } finally {
    host.remove();
  }
}

await checkOriginBoundary({
  frameUrl: 'https://owned-child.example.test/fixture',
  expectedOrigin: 'https://owned-child.example.test',
  expectedMessage: 'owned-fixture-ready',
});

Le fixture enfant doit envoyer son message uniquement lorsque sa propre page est prête et utiliser l'origine déclarée par le parent comme cible de postMessage. Le parent vérifie la fenêtre source, l'origine exacte et le type de message avant de mettre à jour le résultat visible. Un délai d'expiration constitue un échec du fixture, pas la preuve d'un blocage lié à la même origine. Classez séparément les erreurs de navigation, de chargement de frame, de politique et d'application afin qu'une panne réseau ne soit pas signalée comme une décision de sécurité du navigateur.

Pour tester un contrôle de même origine et un candidat cross-origin, gardez le comportement des pages et le schéma des messages identiques, en ne modifiant que la relation d'origine. Utilisez des URL stables et contrôlées ainsi qu'une attente limitée. Le contrôle doit afficher le message attendu. Le candidat doit montrer le comportement cross-origin déclaré, par exemple un message reçu via postMessage alors que l'accès direct au DOM reste indisponible. N'essayez pas d'obtenir des données protégées pour faire office de preuve. Le résultat visible et l'erreur d'accès documentée par le navigateur suffisent pour ce test de frontière.

Le nettoyage doit se trouver dans un chemin finally. Supprimez la frame temporaire, retirez les écouteurs d'événements, annulez les minuteurs et fermez le contexte de navigateur isolé dans le lanceur de tests. Si le fixture a créé un enregistrement serveur synthétique, supprimez-le via un endpoint de test contrôlé et consignez ce nettoyage séparément. Conservez le premier échec d'assertion si le nettoyage échoue lui aussi. Un démontage propre ne prouve pas qu'un système distant a effacé des données sans rapport.

Déployer, surveiller et restaurer

Commencez par inventorier les origines. Dressez la liste des hôtes canoniques de l'application, des hôtes d'assets, des fournisseurs d'identité, des frames clientes, des endpoints d'analyse et des destinations de redirection. Pour chaque dépendance, indiquez si l'application a besoin de rendu, de navigation, de messagerie, de lecture de réponse ou d'accès au DOM. Nommez le propriétaire et le contrat d'autorisation côté serveur. Cet inventaire empêche qu'une hypothèse de même site masque une relation cross-origin et fournit à l'équipe de support un point de départ concret lorsqu'un déploiement change.

Exécutez le fixture de contrôle et le candidat en préproduction avec les noms d'hôte et les politiques de réponse finaux. Notez l'origine finale, la version du navigateur, l'origine de la frame, l'état visible, l'état réseau et le résultat de l'application. Vérifiez qu'une réponse HTTP réussie n'est pas confondue avec une réponse lisible et qu'un résultat de politique du navigateur n'est pas pris pour un refus du serveur. Excluez du rapport le contenu des comptes et les identifiants. Répétez les contrôles après tout changement de CDN, de redirection, de fournisseur d'identité ou de version du navigateur.

Déployez les changements par étapes limitées. Commencez par le fixture géré par l'équipe et la télémétrie des résultats visibles. Modifiez ensuite la politique de réponse ou d'intégration pour une origine de préproduction. Testez alors les fenêtres de connexion, les paiements, les frames clientes, les téléversements et tout flux qui traverse des origines. Confirmez que le canal de messages prévu fonctionne et que l'accès non autorisé au DOM ou aux réponses reste impossible. Ne promouvez le changement que lorsque le parcours utilisateur et sa solution de repli sont compris.

Une restauration doit remettre en place la combinaison précédente de l'application et des politiques, et non supprimer une assertion. Conservez les anciens en-têtes, la carte des redirections et la configuration des frames. Si un changement casse un parcours essentiel, restaurez la dernière configuration valide, relancez les fixtures de contrôle et de candidat, puis classez la frontière en échec. Préservez HTTPS, l'authentification et l'autorisation pendant la restauration. N'élargissez pas la liste des origines autorisées et n'acceptez pas d'origines de message arbitraires pour faire passer un test.

Ce que BotBrowser peut valider

BotBrowser permet d'exécuter des fixtures autorisés dans des contextes contrôlés, mais ne peut pas accorder l'autorisation du serveur et ne remplace pas ses contrôles de sécurité.

BotBrowser prend en charge des contextes de navigateur contrôlés capables d'exécuter des fixtures d'origine autorisés, de comparer les résultats visibles de la politique de même origine et de répéter les observations d'isolation des sites sur une version déclarée. Sa documentation sur l'isolation multicomptes décrit des contextes distincts pour des parcours indépendants. Vous obtenez ainsi des preuves répétables de l'origine finale, du résultat des messages de la frame et du repli de l'application, avec un état synthétique limité au test.

BotBrowser ne modifie pas une origine, n'accorde pas d'autorisation serveur, ne désactive pas les contrôles du navigateur, ne garantit pas une organisation particulière des processus et ne remplace pas les contrôles de sécurité de l'application. Le navigateur, les en-têtes de réponse, l'autorisation serveur et le code applicatif restent responsables de leurs frontières respectives. Une exécution contrôlée réussie montre ce que le navigateur et le déploiement déclarés ont exposé au test. Elle ne certifie ni tous les navigateurs, ni tous les partenaires d'intégration, ni chaque décision d'autorisation côté serveur.

Pour les frontières connexes, consultez le guide du modèle de stockage du navigateur, le guide des frontières CORS du navigateur et le guide de l'isolation cross-origin. Ils couvrent le cloisonnement de l'état, la lisibilité des réponses et les en-têtes d'isolation. Cet article se concentre sur l'identité des origines, l'accès des scripts, la communication intégrée et le rôle de l'isolation des sites.

Consultez le guide CORS du navigateur et le guide de l'isolation cross-origin pour les frontières voisines.

Auteur : Équipe BotBrowser

Sources

• WHATWG HTML: Origins
• MDN: Same-origin policy
• Chromium: Site isolation
• MDN: Window.postMessage
• BotBrowser: Multi-account isolation