Chrome désactive la modification de document.domain

Si votre site Web repose sur la définition de document.domain, vous devez agir.

Maud Nalpas
Eiji Kitamura

Qu'est-ce qui change et pourquoi ?

À partir de Chrome 115, les sites Web ne pourront pas 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 finissent par rendre cette fonctionnalité obsolète 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 autoriser la communication entre les pages de même site, mais d'origines différentes.

Bien que cette technique soit pratique, elle présente un risque pour la 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 avertit les utilisateurs de ne pas l'utiliser.

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

Utilisation actuelle de document.domain

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

Les sites same-site, mais cross-origin ont le même eTLD+1, mais des sous-domaines différents.

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

Supposons qu'une page sur 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 document.domain des deux pages est défini sur 'example.com', le navigateur traite les deux origines comme si elles étaient de 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 cross-origin sur https://parent.example.com contre 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.

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

Problèmes de sécurité liés à 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 d'éviter de l'utiliser.

Par exemple, lorsque deux pages définissent document.domain, elles peuvent faire comme si elles étaient de 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 ouvre l'accès à tous les autres sites hébergés par le même service, ce qui permet aux pirates informatiques d'accéder plus facilement à vos sites. Cela est possible, car document.domain ignore la partie du nom de domaine correspondant au numéro de port.

Pour en savoir plus sur les implications en termes de sécurité de la définition de document.domain, consultez la page "Document.domain" sur MDN.

Compatibilité du navigateur

Comment savoir si mon site est concerné ?

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

Capture d'écran de l'avertissement concernant le problème dans les outils de développement

Vous pouvez également exécuter l'audit de l'API Lighthouse obsolète sur votre site pour trouver toutes les API qui doivent être supprimées de 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 les 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 cette modification en action, même si elle n'a pas encore été déployée 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 qui la composent 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 intéressant d'envisager d'autres solutions qui continuent de prendre en charge les accès cross-origin.

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

Dans la plupart des cas d'utilisation, l'postMessage() d'origine croisée ou l'API Channel Messaging peuvent remplacer document.domain.

Dans l'exemple suivant :

  1. https://parent.example.com requests https://video.example.com within an iframe to manipulate DOM by sending a message via postMessage().
  2. https://video.example.com manipule le DOM dès qu'il reçoit le message et notifie le succès au parent.
  3. https://parent.example.com confirme la réussite.

Le 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
  }
});

Le 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-le pour voir comment il 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 votre question sur Stack Overflow avec le 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é 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 une règle d'administration

Votre administrateur peut également configurer la règle OriginAgentClusterDefaultEnabled sur false pour que document.domain soit 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

Remerciements

Photo de Finan Akbar sur Unsplash