Deux décennies durant, il a suffi d’un peu de code et d’un lien violet pour que n’importe quel site en sache un peu trop sur vos habitudes de navigation. Vingt ans plus tard, Google prend le problème à bras le corps et s’apprête à mettre un vrai terme à cette faille logique tenace.
C’est l’histoire d’un petit effet de style devenu faille de confidentialité malgré lui. Pour celles et ceux qui ne le savent pas, le sélecteur CSS :visited est une pseudo-classe qui permet de styliser les liens hypertextes déjà consultés par l’internaute – autrement dit, ceux que le navigateur reconnaît comme ayant été ouverts auparavant. Un mécanisme pensé pour améliorer la navigation, mais qui s’est révélé bien plus bavard qu’il n’aurait dû l’être. Car s’il permet à l’utilisateur ou l’utilisatrice de repérer les pages déjà visitées, il donne aussi, potentiellement, cette information à d’autres. Un problème connu des navigateurs web depuis plus de 20 ans, et auquel Chrome devrait enfin s’attaquer de manière structurelle.
Une couleur, un script, et vingt ans de pistage toléré
À l’origine, le sélecteur CSS dont il est question ici devait contribuer à fluidifier l’expérience de navigation. Sans entrer dans les détails trop techniques qui le constituent, c’est lui qui gère l’affichage violet des liens web sur lesquels vous avez déjà cliqué, et qui vous permet donc d’éviter de rouvrir une même page dix fois quand vous ne vous souvenez pas l’avoir déjà consultée.
Sauf que derrière son apparente banalité, ce sélecteur a aussi longtemps servi de mouchard. Dès le début des années 2000, des tiers un peu trop curieux ou malveillants ont détourné sa fonction première pour pister discrètement les internautes. Car si ce repère visuel vous aide à retracer votre propre parcours en ligne, il permet aussi, logiquement, à d’autres de le reconstituer à votre place.
Les premières attaques identifiées exploitaient directement le comportement du navigateur. En injectant quelques lignes de script dans une page, n’importe qui d’un peu expérimenté pouvait afficher une liste de liens, puis d’observer la manière dont chacun était stylisé. Si le navigateur appliquait la couleur définie pour les éléments marqués :visited, cela suffisait à conclure que l’URL correspondante figurait dans l’historique local.
Cette technique, connue sous le nom de history sniffing, a été documentée dès les années 2000. Des chercheurs en sécurité ont rapidement soulevé les risques associés, et plusieurs démonstrations ont circulé en ligne pour illustrer les dérives possibles. Certaines plateformes grand public s’en sont même emparées, à leur manière, pour montrer ce qu’un site pouvait inférer sur les habitudes d’un internaute rien qu’en observant l’apparence de quelques liens.
Les premières réponses sont venues du côté de Firefox. Dès 2010, le navigateur a modifié le comportement de certaines fonctions comme getComputedStyle, qui permettaient jusqu’alors de détecter si un lien avait été visité. Une rustine utile pour bloquer les attaques les plus directes, mais qui n’a jamais suffi à régler totalement le problème.
D’autres méthodes ont rapidement pris le relais. Certaines reposaient sur l’inspection du DOM (la structure de la page), d’autres sur des variations de temps de chargement ou des réactions aux interactions de l’internaute. En dépit des protections mises en place, le mécanisme :visited restait exploitable, souvent de façon indirecte, mais suffisamment fiable pour alimenter des techniques de pistage.
Et pendant tout ce temps, Chrome est resté en retrait. Plusieurs rapports de bugs ont été classés sans suite, la faille étant jugée trop ancrée dans le fonctionnement du web pour être corrigée proprement. Pendant plus de vingt ans, cette zone grise est donc restée active, tolérée par Google, et exploitable. Du moins, jusqu’à aujourd’hui.
Vers une gestion plus rigoureuse des liens visités dans Chrome 136
Car Chrome 136 devrait enfin apporter une réponse à la hauteur du problème. Plutôt que de chercher à masquer les effets du sélecteur :visited, Google a choisi de modifier la manière dont le navigateur gère, en interne, les liens déjà consultés. Objectif : faire en sorte qu’un site ne puisse plus déduire votre historique à partir de l’affichage d’un lien vers une page que vous avez visitée ailleurs.
Jusqu’ici, le fonctionnement du sélecteur reposait sur une liste unique d’URL, partagée entre tous les sites. Si vous aviez cliqué sur un lien vers un Site B depuis un Site A, ce lien apparaissait comme visité sur n’importe quel autre Site C, D ou E répertoriant la même adresse Site B. Et c’est précisément ce comportement global qui rendait le mécanisme exploitable.
Avec Chrome 136, cette logique change. Dans sa prochaine mise à jour majeure, prévue pour le 23 avril, le navigateur devrait introduire un partitionnement du stockage des liens visités, en s’appuyant sur trois éléments :
- l’URL du lien,
- le site de niveau supérieur (top-level site, celui ouvert dans la barre d’adresse),
- l’origine du cadre (frame origin, c’est-à-dire l’environnement dans lequel le lien est rendu, par exemple dans une iframe ou pas).
En d’autres termes, un lien ne pourra apparaître comme « déjà visité » que s’il est affiché dans le même contexte que celui dans lequel il a été ouvert – c’est-à-dire avec la même adresse, le même site principal et dans un cadre d’affichage identique. Affiché depuis un autre environnement, il sera traité comme un lien neuf.
Cette évolution doit pouvoir bloquer les tentatives de déduction, même indirectes. Elle rompt la logique d’une liste globale consultable depuis n’importe quel environnement, en cloisonnant l’information au sein de chaque origine. Les attaques reposant sur des styles CSS ou sur l’inspection du DOM, les analyses différentielles (qui comparent les comportements selon que le lien est visité ou non), ou encore les signaux déclenchés par l’interaction de l’internaute deviennent alors inopérantes, faute d’indicateur exploitable.
Pour ne pas pénaliser l’expérience de navigation, une exception a toutefois été prévue pour les liens internes. Un site pourra continuer à styliser comme « déjà visités » les liens vers ses propres sous-pages, même si celles-ci ont été ouvertes depuis un autre contexte. L’idée est ici d’éviter les effets visuels incohérents pour l’internaute, qui s’attend à voir différenciées les pages déjà consultées, quel que soit le chemin emprunté.
Google estime que dans ce cas, le site dispose déjà d’autres moyens pour savoir si une page interne a été visitée, et que le risque de fuite est limité. Mais cette exception reste strictement encadrée : elle ne s’applique pas aux contenus tiers, ni aux pages affichées dans des cadres externes (iframes), qui restent cloisonnés.
En bref, cette correction marque un vrai tournant. Non seulement parce qu’elle met fin à une faille ancienne, mais aussi parce qu’elle traduit un changement d’approche : plutôt que de patcher les effets, Chrome revoit la mécanique de base. Et s’attaque enfin, structurellement, à une vulnérabilité aussi persistante que sous-estimée.
Sources : Google, The Register
