Chrome désactivera la modification de document.domain pour assouplir la règle de même origine

Si votre site Web repose sur le paramètre document.domain, votre action est requise.

Eiji Kitamura

Actualités

• 30 mai 2023: nous avons annoncé que l'abandon du setter document.domain prendra effet dans Chrome 115.
• 7 avril 2023: nous avons identifié un problème avant de déployer ce changement dans Chrome 112. Le setter document.domain à supprimer par défaut est actuellement suspendu, et le nouveau jalon de publication n'est pas encore déterminé. Veuillez revenir sur cet article de blog ou vous abonner à blink-dev et à ce fil de discussion.
• 20 janvier 2023 : calendrier mis à jour : le setter document.domain sera supprimé par défaut à partir de Chrome 112. Une mention concernant la règle d'entreprise est également ajoutée pour contrôler le comportement de document.domain.
• 25 juillet 2022 : calendrier mis à jour : le setter document.domain sera supprimé par défaut à partir de Chrome 109.
• 4 février 2022: mise à jour avec le nouveau calendrier. Un avertissement s'affichera dans le panneau "Problèmes" à partir de Chrome 100, et le setter document.domain sera supprimé par défaut à partir de Chrome 106.

Avertissement:Si votre site Web repose sur l'assouplissement de la règle d'origine commune via document.domain, une action de votre part est requise. Poursuivez votre lecture pour en savoir plus sur ce changement ou passez à la section Code alternatif pour la communication inter-origine.

document.domain a été conçu pour obtenir ou définir le nom d'hôte de l'origine.

Dans Chrome, les sites Web ne peuvent pas définir document.domain. Vous devez utiliser d'autres approches, telles que postMessage() ou l'API Channel Messaging, pour communiquer des origines multiples. Nous prévoyons de déployer ce changement dans Chrome 112 au plus tôt, mais cela dépend de la réponse à l'intention de livraison.

Si votre site Web s'appuie sur un assouplissement des règles SOP via document.domain pour fonctionner correctement, il devra envoyer un en-tête Origin-Agent-Cluster: ?0, comme tous les autres documents nécessitant ce comportement (notez que document.domain n'a aucun effet si un seul document le définit).

Pourquoi rendre document.domain immuable ?

De nombreux sites Web définissent document.domain pour autoriser la communication entre les pages du même site, mais d'origine différente.

Terme clé:Les sites du même site, mais d'origine différente, ont le même eTLD+1, mais des sous-domaines différents.

Voici comment l'utiliser:

Supposons qu'une page sur https://parent.example.com intègre une page iFrame à partir de https://video.example.com. Ces pages ont le même eTLD+1 (example.com) avec des sous-domaines différents. Lorsque l'document.domain des deux pages est défini sur 'example.com', le navigateur traite les deux origines comme s'il s'agissait de la même origine.

Définissez document.domain pour https://parent.example.com:

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Définissez le document.domain pour https://video.example.com:

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Vous pouvez désormais créer une manipulation DOM inter-origine sur https://parent.example.com par rapport à https://video.example.com.

Les sites Web définissent document.domain pour permettre aux documents du même site de communiquer plus facilement. Étant donné que cette modification assouplit la règle d'origine commune, la page parente peut accéder au document de l'iFrame et parcourir l'arborescence DOM, et inversement.

Il s'agit d'une technique pratique, mais elle présente un risque de sécurité.

Problèmes de sécurité avec document.domain

Les problèmes de sécurité liés à document.domain ont entraîné une modification de la spécification qui avertit les utilisateurs de ne pas l'utiliser. La discussion en cours avec d'autres fournisseurs de navigateurs va dans le même sens.

Par exemple, lorsque deux pages définissent document.domain, elles peuvent prétendre avoir la même origine. Ce point est particulièrement important lorsque ces pages utilisent un service d'hébergement partagé avec différents sous-domaines. Le paramètre document.domain permet d'accéder à tous les autres sites hébergés par ce même service, ce qui facilite l'accès des pirates informatiques à vos sites. Cela est possible, car document.domain ignore la partie du numéro de port du domaine.

Pour en savoir plus sur les implications de sécurité du paramètre document.domain, consultez la page"Document.domain" sur MDN.

Chrome prévoit de rendre document.domain immuable dans Chrome 112.

Comment savoir si mon site est concerné ?

Si votre site Web est concerné par cette modification, un avertissement s'affiche dans le panneau "Problèmes des outils de développement" de Chrome. Remarquez le drapeau jaune dans le coin supérieur droit.

Lorsque document.domain est modifié, un avertissement s'affiche dans le panneau "Problèmes".

Si vous avez configuré un point de terminaison de reporting, vous recevrez également des rapports d'abandon. Découvrez comment utiliser l'API Reporting avec des services de collecte de rapports existants ou en créant votre propre solution interne.

Vous pouvez exécuter l'audit des API obsolètes de Lighthouse sur votre site pour trouver toutes les API qui sont prévues pour être supprimées de Chrome.

Communication inter-origine alternative

Pour le moment, vous avez trois options pour remplacer document.domain sur votre site Web.

Utiliser postMessage() ou l'API Channel Messaging

Dans la plupart des cas d'utilisation, les postMessage() multi-origines ou l'API Channel Messaging peuvent remplacer document.domain.

Dans l'exemple suivant :

1. https://parent.example.com demande https://video.example.com dans un iFrame pour manipuler le DOM en envoyant un message via postMessage().
2. https://video.example.com manipule le DOM dès qu'il reçoit le message et informe le parent du succès.
3. https://parent.example.com confirme la réussite.

Sur https://parent.example.com:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

Sur https://video.example.com:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

Essayez-la pour voir comment elle fonctionne. Si vous avez des exigences spécifiques qui ne fonctionneront pas avec postMessage() ou l'API Channel Messaging, veuillez nous en informer sur Twitter via @ChromiumDev ou poser votre question sur Stack Overflow en utilisant une balise document.domain.

En dernier recours, envoyez l'en-tête Origin-Agent-Cluster: ?0.

Si vous avez de bonnes raisons de continuer à définir document.domain, vous pouvez envoyer l'en-tête de réponse Origin-Agent-Cluster: ?0 avec le document cible.

Origin-Agent-Cluster: ?0

L'en-tête Origin-Agent-Cluster indique au navigateur si le document doit être géré ou non par le cluster d'agents selon l'origine. Pour en savoir plus sur Origin-Agent-Cluster, consultez Demander l'isolation des performances avec l'en-tête Origin-Agent-Cluster.

Lorsque vous envoyez cet en-tête, votre document peut continuer à définir document.domain même après qu'il est devenu immuable par défaut.

Configurer OriginAgentClusterDefaultEnabled pour les règles d'entreprise

Votre administrateur peut éventuellement configurer la règle OriginAgentClusterDefaultEnabled sur false pour que document.domain puisse être défini par défaut sur les instances Chrome de votre organisation. Pour en savoir plus, consultez la page Liste et gestion des règles Chrome Enterprise | Documentation.

Compatibilité du navigateur

• La spécification Origin indique que cette fonctionnalité doit être supprimée.
• Mozilla considère que le prototypage de la désactivation de document.domain par défaut est intéressant.
• WebKit a indiqué qu'il était plutôt favorable à l'abandon du setter document.domain.

Ressources

• Document.domain : API Web | MDN
• Isolation de l'origine et abandon de document.domain
• Abandon de document.domain. · Problème 564 · w3ctag/design-reviews

Remerciements

Photo de Braydon Anderson sur Unsplash