DBSC dans Chrome : comment Google rend les cookies de session volés inutilisables
ce qui est déployé, et ce qui ne l’est pas.

Un cookie de session est le petit jeton déposé dans votre navigateur après une connexion réussie. Il évite de ressaisir un mot de passe à chaque page. Sa faiblesse est structurelle : c’est un jeton au porteur. Quiconque le détient est traité comme vous, depuis n’importe quelle machine, sans mot de passe, et sans que la double authentification s’interpose puisque celle-ci a déjà été franchie au moment de la connexion.

C’est précisément ce que ciblent les logiciels dérobeurs d’informations. Une fois installés, ils extraient silencieusement les cookies présents dans les navigateurs, ou attendent la prochaine connexion pour les capter, puis les envoient vers un serveur contrôlé par l’attaquant. Google cite nommément la famille LummaC2 parmi les plus perfectionnées sur ce terrain. Les lots récupérés sont ensuite regroupés, échangés ou revendus.

L’ampleur du phénomène a été chiffrée par des travaux publiés en 2026 : plus de cinquante millions de lots issus de ces malwares auraient été traités au cours de l’année 2025, en progression de l’ordre de 70 % sur un an, et une large majorité des entreprises récemment compromises voyaient apparaître des identifiants d’entreprise dans ces lots dans les six mois précédant l’incident. Ces chiffres proviennent d’un éditeur de solutions de sécurité et relèvent de l’estimation sectorielle, pas d’une mesure officielle.

La conséquence se lit dans les affaires de compromission massive, comme celle décrite dans notre analyse de la fuite portant sur des centaines de millions de comptes en France. Une session valide vaut souvent davantage qu’un mot de passe : elle contourne l’étape de vérification.

Device Bound Session Credentials, littéralement identifiants de session liés à l’appareil, s’attaque au problème par sa racine : plutôt que de détecter un usage anormal après coup, le mécanisme rend le cookie techniquement inutilisable ailleurs.

Le principe repose sur une paire de clés cryptographiques générée par Chrome au moment de la connexion. La clé publique part vers le serveur, la clé privée est stockée dans un composant de sécurité matériel dont elle ne peut pas être extraite. Les cookies de session deviennent alors de très courte durée, renouvelables uniquement après que Chrome a prouvé qu’il détient toujours cette clé privée.

Le calendrier public est le suivant. Le projet a été annoncé en avril 2024, puis testé en essai d’origine. En avril 2026, Google a annoncé la disponibilité générale pour les utilisateurs de Chrome sous Windows, avec la version 146, tout en précisant que le déploiement s’effectue progressivement. Le support macOS, alors présenté comme prévu pour une version ultérieure, a depuis été livré, adossé au Secure Enclave, avec là encore un déploiement graduel.

Un volet complémentaire concerne les comptes professionnels. Pour les clients de la suite bureautique de Google, la fonction est activée par défaut, sans réglage d’administration permettant de la désactiver, avec un déploiement progressif engagé fin mai 2026 et des journaux d’audit consultables dans l’outil d’investigation de sécurité. Cette évolution s’inscrit dans une série d’ajustements du navigateur, après par exemple la simplification du remplissage automatique.

Toute la solidité du dispositif repose sur une propriété matérielle : l’existence d’un composant capable d’utiliser une clé sans jamais la révéler au système qui le sollicite.

Sous Windows, ce rôle revient au module de plateforme sécurisée, communément désigné par son sigle anglais TPM. Sa version 2.0 constitue une exigence d’installation de Windows 11, ce qui rend le composant présent sur l’immense majorité des machines récentes. Sous macOS, la fonction équivalente est assurée par le Secure Enclave intégré aux processeurs Apple, ce qui restreint le dispositif aux machines dotées de cette architecture.

Sur un appareil dépourvu de composant compatible, Chrome revient simplement au comportement classique, sans casser l’authentification ni provoquer de régression visible. La protection ne s’applique alors pas. Ce point mérite d’être souligné pour les parcs d’entreprise vieillissants et pour les machines personnelles utilisées en dehors des équipements administrés, où le matériel ancien reste répandu.

Google a indiqué travailler sur des clés logicielles destinées à étendre une forme de protection aux machines sans composant sécurisé. Cette évolution figure dans une feuille de route publiée, aux côtés de la liaison de sessions fédérées pour l’authentification unique entre domaines et d’un mode d’enregistrement avancé s’appuyant sur des certificats ou des clés matérielles. Aucune date n’a été communiquée pour ces trois chantiers.

C’est la précision la plus importante, et elle change entièrement la portée de l’annonce : la protection n’est pas activée automatiquement pour l’ensemble du web.

Chrome fournit la moitié navigateur du mécanisme. L’autre moitié incombe au site. Concrètement, un service qui souhaite en bénéficier doit modifier son parcours de connexion pour émettre un en-tête d’enregistrement de session, exposer une configuration de session, basculer vers des cookies de courte durée et ajouter un point de renouvellement capable de vérifier la preuve de possession de la clé. Sans ces développements, rien ne change.

Les services de Google sont concernés par construction, ce qui couvre déjà une part très large des connexions quotidiennes. Pour le reste, l’adoption dépendra de la volonté de chaque éditeur, et l’écosystème commence tout juste à s’outiller : des bibliothèques côté serveur apparaissent, encore jeunes et parfois explicitement expérimentales, ce qui invite à la prudence pour un déploiement en production.

Les organisations les plus exposées ont pourtant intérêt à l’examiner sérieusement. Le secteur public figure année après année parmi les cibles les plus visées, comme le rappelle notre analyse des cyberattaques contre l’administration en Europe, et le durcissement réglementaire décrit dans notre article sur les nouvelles règles préparées par la CNIL pousse dans le même sens : documenter les mesures techniques déployées devient une obligation autant qu’une bonne pratique.

Le mécanisme a été présenté dès l’origine comme une spécification ouverte, travaillée avec Microsoft et destinée à devenir une norme du web. L’état d’avancement mérite toutefois d’être décrit sans embellissement.

Chrome est aujourd’hui le seul navigateur à proposer la fonctionnalité en disponibilité générale, sous Windows puis sous macOS. Du côté du navigateur de Microsoft, un essai d’origine a été mené puis s’est achevé à l’automne 2025, sans annonce de disponibilité générale à ce jour. Les navigateurs de Mozilla et d’Apple observent l’évolution du dossier sans engagement public d’implémentation.

Cette situation n’a rien d’inhabituel pour une spécification jeune, mais elle a une conséquence pratique. Une entreprise qui implémenterait le protocole côté serveur protégerait aujourd’hui ses utilisateurs sous Chrome, et laisserait les autres au régime classique. Le retour sur investissement dépend donc directement de la répartition des navigateurs dans son audience.

Une donnée manque encore pour évaluer l’efficacité réelle du dispositif : des mesures indépendantes. Google indique avoir constaté une réduction du vol de sessions pendant la phase d’essai, sans publier de méthodologie ni de volumétrie détaillée. Les éditeurs de sécurité qui commentent le sujet ont pour la plupart un produit à vendre sur le même terrain. Le recul manquera encore plusieurs mois avant qu’un bilan chiffré et vérifiable soit disponible.

Un point positif mérite d’être noté. La spécification étant publique et le protocole reposant uniquement sur des en-têtes HTTP, une implémentation serveur réalisée aujourd’hui restera valable si d’autres navigateurs l’adoptent. Le travail n’est pas spécifique à un éditeur, contrairement à ce qu’on observe souvent avec les mécanismes de sécurité propriétaires.