Chrome désactive la modification de document.domain

Si votre site Web repose sur la configuration de document.domain, votre action est requise.

Maud Nalpas

Twitter GitHub

Eiji Kitamura

Twitter GitHub Glitch Mastodon

Avertissement:Comme annoncé en janvier 2022, nous abandonnons le setter document.domain à partir de Chrome 115. Si votre site Web repose sur un assouplissement de la règle d'origine commune via document.domain, une action immédiate est requise. Notez que l'utilisation du setter document.domain (document.domain = ...) ne génère pas d'exception. Elle cessera seulement d'être appliquée. Poursuivez votre lecture pour en savoir plus sur les raisons de cette modification ou passez à un autre code que vous pouvez implémenter.

Qu'est-ce qui change et pourquoi ?

À partir de Chrome 115, les sites Web ne pourront plus définir document.domain: Chrome rendra document.domain immuable. Pour communiquer entre les origines, vous devez utiliser d'autres approches, telles que postMessage() ou l'API Channel Messaging.

Notez que cette modification sera déployée progressivement.

D'autres navigateurs devraient finir par l'abandonner et la supprimer. Pour en savoir plus, consultez la section Compatibilité des navigateurs.

Pourquoi rendre document.domain immuable ?

document.domain a été conçu pour obtenir ou définir le nom d'hôte de l'origine. De nombreux sites Web définissent document.domain pour permettre la communication entre des pages identiques, mais multi-origines.

Bien qu'il s'agisse d'une technique pratique, elle présente un risque de sécurité, car elle assouplit la règle de même origine. Les problèmes de sécurité liés à document.domain ont entraîné une modification de la spécification, qui conseille aux utilisateurs de ne pas l'utiliser.

En détail: Pourquoi rendre document.domain immuable ?

Utilisation actuelle de document.domain

De nombreux sites Web configurent document.domain pour permettre la communication entre des pages sur le même site, mais multi-origines.

Les sites multi-origines sur un même site ont le même eTLD+1, mais des sous-domaines différents.

Voici comment document.domain était utilisé jusqu'à présent:

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.

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é de la configuration de document.domain, consultez la page"Document.domain" sur MDN.

Compatibilité du navigateur

• La spécification HTML indique que la fonctionnalité doit être supprimée.
• 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.
• Discuter avec d'autres fournisseurs de navigateurs
• Demande d'extraction du groupe de travail WhatWG / HTML (en attente de tests)

Comment savoir si mon site est concerné ?

Avertissement:Notez qu'à partir de Chrome 115, l'utilisation du setter document.domain ne générera pas d'exception, conformément à la spécification. Elle cessera seulement d'être appliquée.

Si votre site Web est concerné par cette modification, Chrome vous avertit dans le panneau "Problèmes liés aux outils de développement". Cet avertissement a été ajouté en 2022. Notez le drapeau jaune dans l'angle supérieur droit des outils de développement.

Vous pouvez également vérifier l'audit des API obsolètes pour votre site afin d'identifier toutes les API dont la suppression est programmée dans Chrome.

Si vous avez configuré l'API Reporting, Chrome vous a envoyé des rapports d'abandon pour vous informer de cet abandon à venir. Découvrez comment utiliser l'API Reporting avec des services de collecte de rapports existants ou en créant votre propre solution interne.

Comment puis-je constater ce changement ?

La modification sera déployée progressivement, à partir de Chrome 115. Pour voir concrètement ce changement, même s'il n'a pas déjà été déployé dans votre navigateur Chrome, vous pouvez l'activer comme suit:

1. Ouvrir chrome://flags/#origin-agent-cluster-default
2. Sélectionnez Activer.
3. Redémarrez Chrome.

Quelles alternatives puis-je utiliser ?

La meilleure option consiste à ne pas modifier du tout document.domain, par exemple en hébergeant la page et tous les frames constitutifs sur la même origine. Cela fonctionne avec toutes les versions de tous les navigateurs. Cependant, cela peut nécessiter une refonte importante d'une application. Il est donc utile d'examiner également les alternatives qui continuent à accepter les accès multi-origines.

Utiliser postMessage() ou l'API Channel Messaging au lieu de document.domain

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.

Tous les autres documents nécessitant ce comportement devront également envoyer un Origin-Agent-Cluster (notez que document.domain n'a aucun effet si un seul document le définit).

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.

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 Finan Akbar, publiée sur Unsplash