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, une action est requise de votre part.

Eiji Kitamura

Twitter GitHub Glitch Mastodon

régulières

• 30 mai 2023: nous avons annoncé que l'abandon du setter document.domain entrera en vigueur dans Chrome 115.
• 7 avril 2023: nous avons identifié un problème avant d'appliquer cette modification dans Chrome 112. Le setter document.domain à supprimer par défaut est actuellement suspendu et le nouveau jalon de livraison n'est pas encore déterminé. Veuillez consulter cet article de blog ou vous abonner à blink-dev et à ce fil de discussion.
• 20 janvier 2023: mise à jour du calendrier – La méthode setter document.domain sera supprimée par défaut à partir de Chrome 112. En outre, une mention concernant la règle d'entreprise permettant de contrôler le comportement de document.domain a été ajoutée.
• 25 juillet 2022: mise à jour du calendrier – La méthode setter document.domain sera supprimée par défaut à partir de Chrome 109.
• 4 février 2022: mise à jour avec le nouveau calendrier. À partir de Chrome 100, un avertissement s'affichera dans le panneau "Problèmes", et nous supprimerons le setter document.domain par défaut à partir de Chrome 106.

Avertissement:Si votre site Web repose sur un assouplissement de la règle de même origine via document.domain, une action est requise de votre part. Poursuivez votre lecture pour en savoir plus sur les raisons de cette modification ou passez au code alternatif pour la communication multi-origine.

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

Sur Chrome, les sites Web ne pourront pas configurer document.domain. Vous devez utiliser d'autres approches, telles que postMessage() ou l'API Channel Messaging, pour communiquer entre les origines. Nous ciblons Chrome 112 de sorte que cette modification soit intégrée au plus tôt, mais cela dépend de la réponse à l'Intent to Ship (Intent d'expédition).

Si votre site Web s'appuie sur l'assouplissement de la règle d'origine commune 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 configurent document.domain pour permettre la communication entre des pages sur le même site, mais multi-origines.

Terme clé:les sites sur le même site mais multi-origines ont le même eTLD+1, mais des sous-domaines différents.

Voici comment il est utilisé:

Imaginons qu'une page de https://parent.example.com intègre une page iFrame provenant de https://video.example.com. Ces pages ont le même eTLD+1 (example.com) avec des sous-domaines différents. Lorsque le paramètre document.domain des deux pages est défini sur 'example.com', le navigateur traite les deux origines comme si elles avaient 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 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 maintenant créer une manipulation DOM multi-origine sur https://parent.example.com pour https://video.example.com.

Les sites Web définissent document.domain pour faciliter la communication des documents sur le même site. Étant donné que cette modification assouplit la règle de même origine, la page parente peut accéder au document de l'iFrame et traverser l'arborescence DOM, et inversement.

Cette technique est pratique, mais elle présente un risque de sécurité.

Problèmes de sécurité concernant 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. Les discussions actuelles avec d'autres fournisseurs de navigateurs vont dans la même direction.

Par exemple, lorsque deux pages définissent document.domain, elles peuvent se faire passer pour la même origine. Cela est particulièrement important lorsque ces pages utilisent un service d'hébergement partagé avec différents sous-domaines. La configuration de 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 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, Chrome vous en avertit dans le panneau "Problèmes liés aux outils de développement". Notez le drapeau jaune dans l'angle 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 vérifier l'audit des API obsolètes de LightHouse pour votre site afin de rechercher toutes les API dont la suppression est planifiée dans Chrome.

Autre communication multi-origine

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

Utiliser postMessage() ou l'API Channel Messaging

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

Dans l'exemple suivant :

1. https://parent.example.com demande https://video.example.com au sein d'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 de la réussite de l'opération.
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 et découvrez comment elle fonctionne. Si vous avez des exigences spécifiques qui ne fonctionnent pas avec postMessage() ou l'API Channel Messaging, contactez-nous sur Twitter via @ChromiumDev ou posez une question sur Stack Overflow avec un tag 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 la valeur document.domain, même s'il devient immuable par défaut.

Configurer OriginAgentClusterDefaultEnabled pour la règle 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 Liste et gestion des règles Chrome Enterprise | Documentation.

Compatibilité du navigateur

• La spécification d'origine indique que l'élément géographique doit être supprimé.
• Mozilla envisage de désactiver document.domain par défaut au besoin d'un prototypage.
• WebKit indique qu'il est assez positif à propos de l'abandon du setter document.domain.

Ressources

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

Remerciements

Photo de Braydon Anderson, publiée sur Unsplash