Chrome désactive la modification de document.domain

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

Maud Nalpas

Eiji Kitamura

Avertissement:Comme nous l'avons annoncé en janvier 2022, nous allons abandonner le setter document.domain à partir de Chrome 115. Si votre site Web s'appuie sur un assouplissement des règles SOP via document.domain, vous devez prendre des mesures immédiates. Notez que l'utilisation du setter document.domain (document.domain = ...) n'entraîne pas d'exception. Elle ne sera plus appliquée. Poursuivez votre lecture pour en savoir plus sur ce changement ou passez directement à l'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 via différentes origines, vous devez utiliser d'autres approches, telles que postMessage() ou l'API Channel Messaging.

Notez que ce changement sera déployé progressivement.

Nous nous attendons à ce que d'autres navigateurs abandonnent et suppriment cette fonctionnalité à terme. 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 autoriser la communication entre les pages du même site, mais d'origine différente.

Bien que cette technique soit 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 met en garde les utilisateurs contre son utilisation.

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

Comment document.domain est utilisé aujourd'hui

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

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 document.domain était utilisé jusqu'à présent:

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 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.

Par exemple, lorsque deux pages définissent document.domain, elles peuvent prétendre avoir la même origine. Cela 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.

Compatibilité du navigateur

• La spécification HTML indique que cette fonctionnalité doit être supprimée.
• Mozilla considère que la désactivation de document.domain par défaut mérite d'être prototypée.
• WebKit a indiqué qu'il était favorable à l'abandon du setter document.domain.
• Discussions avec d'autres fournisseurs de navigateurs
• Pull request du groupe de travail WHATWG / HTML (expérience d'expérimentation en attente)

Comment savoir si mon site est concerné ?

Avertissement:Notez qu'à partir de Chrome 115, l'utilisation du setter document.domain n'entraînera plus d'exception, conformément aux spécifications. Il ne sera plus appliqué.

Si votre site Web est concerné par ce changement, Chrome vous en avertit dans le panneau "Problèmes" de DevTools. Cet avertissement a été ajouté en 2022. Notez le drapeau jaune en haut à droite des outils pour les développeurs.

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

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

Comment voir ce changement en action ?

Cette modification sera déployée progressivement à partir de Chrome 115. Pour voir ce changement en action, même s'il n'a pas encore é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 document.domain du tout, par exemple en hébergeant la page et tous les cadres constituants sur la même origine. Cela fonctionne dans toutes les versions de tous les navigateurs. Toutefois, cela peut nécessiter une refonte importante d'une application. Il est donc également intéressant d'examiner d'autres solutions qui continuent de prendre en charge les accès inter-origines.

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

Dans la plupart des cas d'utilisation, postMessage() 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é par le cluster d'agents selon l'origine ou non. 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.

Tous les autres documents qui nécessitent 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 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.

Ressources

• Document.domain : API Web | MDN
• Isolation des origines et abandon de document.domain
• Obsolescence de document.domain. · Problème 564 · w3ctag/design-reviews

Remerciements

Photo de Finan Akbar sur Unsplash