Comment le vol de session a dépassé les anciennes défenses
Pendant la dernière décennie, les cookies de navigateur étaient le ventre mou de l’identité web. Un attaquant capable d’installer un infostealer comme RedLine, Lumma ou StealC sur un endpoint pouvait exfiltrer silencieusement des cookies d’authentification et les rejouer depuis n’importe quelle machine, contournant mots de passe et la plupart des facteurs MFA. Le rapport mondial 2026 de CrowdStrike et la note de février 2026 du Google Threat Intelligence Group sur le phishing assisté par IA notent que le vol de session via infostealer reste l’un des vecteurs d’intrusion à plus forte croissance, avec des breakout times qui se réduisent et des marketplaces de sessions volées qui se professionnalisent.
Les défenses traditionnelles réagissent après coup. Détection d’anomalies, réputation IP, coupures de session par les fournisseurs d’identité : tout cela répond à un abus déjà en cours. DBSC change ce schéma en liant la session elle-même à une clé cryptographique non exportable, conservée dans le matériel de l’appareil d’origine.
Ce que DBSC fait au niveau du protocole
Device Bound Session Credentials est un draft W3C développé au sein du Web Application Security Working Group, avec Google et Microsoft comme co-concepteurs principaux et Okta comme participant identité précoce. Quand un serveur ouvre une session, le navigateur génère une paire de clés publique-privée à l’intérieur du matériel sécurisé : le Trusted Platform Module sous Windows ou le Secure Enclave sous macOS. La clé privée ne quitte jamais cette frontière matérielle. Régulièrement, le serveur défie le navigateur de prouver qu’il possède toujours la clé privée, et le navigateur signe le défi avec le matériel TPM.
Voler le cookie ne suffit plus. Il faudrait aussi extraire la clé liée à l’appareil, qui est protégée structurellement par le TPM et inaccessible aux malwares en mode utilisateur. Le protocole est aussi privacy-preserving par design : seule la clé publique par session est partagée avec le serveur, sans identifiant d’appareil ni données d’attestation, donc DBSC ne peut pas servir de fingerprinting cross-site.
Publicité
Le déploiement Chrome 146 et son périmètre
Chrome 146 livre DBSC à Windows 10 version 1903 et plus, ainsi qu’à tous les systèmes Windows 11 avec TPM 2.0 ou matériel compatible Windows Hello. Google indique que ce périmètre couvre environ 85 % des installations Windows Chrome actives. Le support macOS arrivera dans une version Chrome ultérieure via le Secure Enclave, et Google explore le stockage logiciel de clés comme repli pour les appareils sans matériel sécurisé dédié.
Pour les administrateurs Workspace, Google a publié une fonctionnalité bêta liée, « Prevent cookie theft with session binding », qui permet aux administrateurs d’exiger des sessions DBSC pour les connexions Google Workspace. En tests internes et lors d’origin trials précédents, Google a indiqué une réduction mesurable du vol de session sur ses propres propriétés, et The Hacker News cite un chiffre de 94 % de tentatives de vol bloquées en scénarios contrôlés.
Ce que DBSC ne résout pas
DBSC est un contrôle solide, mais ce n’est pas une réponse complète à l’abus de credentials. Il ne protège que les sessions où navigateur et serveur l’activent, ce qui veut dire que le bénéfice large dépend des fournisseurs d’identité, plateformes SaaS et banques mettant à jour leur gestion de session. Les flux de phishing qui capturent les credentials avant toute session ne sont pas affectés. Un malware qui détourne le processus navigateur en cours, plutôt que d’exfiltrer les cookies, peut encore agir à l’intérieur de la session légitime tant que l’utilisateur est actif. Les attaques de remote-control où l’attaquant pilote la machine de la victime contournent entièrement le protocole.
DBSC est donc à comprendre comme une couche dans une posture de défense en profondeur qui inclut aussi MFA résistant au phishing basé sur FIDO2 et WebAuthn, détection endpoint axée sur le comportement infostealer, et durées de session plus courtes pour les actions sensibles.
Ce que les équipes identité doivent faire maintenant
La feuille de route pratique 2026 a quatre étapes. Premièrement, inventorier quelles applications SaaS et internes exposent des cookies de session à longue durée et lesquelles supportent déjà FIDO2 ou WebAuthn pour la ré-authentification sur les actions sensibles. Deuxièmement, suivre les annonces de support DBSC chez les principaux fournisseurs d’identité, car l’adoption par Okta, Microsoft Entra, Google Workspace et Ping déterminera l’étendue de la protection. Troisièmement, durcir la posture endpoint contre les infostealers, puisque le modèle de menace suppose que le malware peut déjà être présent. Quatrièmement, piloter la bêta Workspace de session-binding ou des contrôles équivalents sur une population réduite avant toute application large.
La direction long terme est claire. L’identité web va vers des sessions plus courtes, des preuves liées à l’appareil et des racines de confiance matérielles. DBSC est l’un des signaux les plus concrets jusqu’ici que l’industrie a accepté que la détection réactive seule ne suffit plus.
Ce que les équipes identité doivent faire maintenant
L’adoption de l’écosystème DBSC prendra 12 à 24 mois. Cette fenêtre n’est pas une raison d’attendre — c’est une opportunité d’achever le travail fondamental qui rend la défense de session matérielle efficace une fois qu’elle arrive. Les quatre actions suivantes accumulent une valeur sécurité complémentaire quelle que soit la date à laquelle les fournisseurs d’identité livreront le support DBSC.
1. Inventorier les cookies de session à longue durée et les raccourcir maintenant
La réduction de risque immédiate la plus directe ne nécessite aucun outillage nouveau. Auditez chaque application interne et SaaS pour les configurations de timeout de session et identifiez celles qui émettent des cookies d’une durée supérieure à 8 heures. Selon le Rapport Global des Menaces CrowdStrike 2026, le temps médian entre l’exfiltration d’un cookie infostealer et la première tentative de replay est descendu sous 4 heures — ce qui signifie qu’un cookie d’une durée de 24 heures est fonctionnellement une fenêtre de mouvement latéral de 24 heures pour un attaquant qui dispose déjà de l’appareil. Raccourcir les sessions d’applications à hauts privilèges à 4 heures ou moins ferme la fenêtre de replay sans nécessiter de modifications au niveau du navigateur. Pour les applications bancaires et de paie, 30 à 60 minutes avec ré-authentification sur les actions sensibles est la norme appropriée.
2. Enregistrer les appareils Windows dans des politiques de credentials TPM avant l’arrivée de DBSC
Chrome 146 couvre environ 85 % des installations actives de Chrome sur Windows avec TPM 2.0. Avant que votre fournisseur d’identité ne livre le support DBSC, utilisez la même infrastructure TPM pour un contrôle différent mais adjacent : exigez que les appareils Windows accédant aux applications sensibles disposent d’une attestation d’état TPM valide via les politiques de conformité device de Microsoft Entra ou la vérification d’endpoint BeyondCorp de Google. Cela établit le modèle de confiance device que DBSC étendra finalement à la couche session. Les organisations qui sautent la confiance device aujourd’hui auront deux étapes d’intégration à l’arrivée de DBSC ; celles qui l’implémentent maintenant n’en auront qu’une. Les documentations de Microsoft Entra Conditional Access et Okta Device Trust fournissent des guides d’enregistrement étape par étape pour la conformité device TPM.
3. Durcir les défenses endpoint contre les familles d’infostealers ciblant les artefacts navigateur
DBSC élimine la valeur de replay des cookies volés, mais uniquement pour les sessions enregistrées. Les infostealers comme Lumma, RedLine et StealC ne se spécialisent pas seulement dans le vol de cookies — ils exfiltrent aussi les mots de passe sauvegardés, les cartes de crédit stockées par le navigateur et les fichiers locaux. Le Rapport Global des Menaces CrowdStrike 2026 et le Threat Intelligence Group de Google identifient tous deux cette catégorie de malware comme le vecteur d’accès initial à la croissance la plus rapide. Les règles EDR ciblant spécifiquement l’exfiltration d’artefacts navigateur — accès inhabituel de processus au cookie store ou au credential store du navigateur — réduisent la fenêtre entre infection et détection indépendamment de l’adoption DBSC. Les règles de réduction de la surface d’attaque de Microsoft Defender for Endpoint et le framework IOA personnalisé de CrowdStrike fournissent tous deux des règles pré-construites pour ce pattern.
4. Suivre les annonces de support DBSC comme une étape de release, pas comme une actualité de fond
Okta, Microsoft Entra et Google Workspace sont les trois fournisseurs d’identité dont le support DBSC déterminera si la plupart des sessions entreprises bénéficient d’une liaison matérielle. Surveillez les notes de publication sécurité et les changelogs développeur de chaque fournisseur pour les déclarations de support DBSC — pas les annonces marketing. Quand un fournisseur livre le support DBSC, la fenêtre de migration pour les tenants entreprise est typiquement de 60 à 90 jours. Les équipes identité qui ont déjà achevé l’inventaire device et raccourci les durées de session pourront activer les sessions protégées par DBSC la semaine du lancement de la fonctionnalité. Le dépôt GitHub de la spécification DBSC du W3C Web Application Security Working Group est la source faisant autorité pour suivre les révisions du protocole.
Sources et lectures complémentaires
- Protecting Cookies with Device Bound Session Credentials — Google Online Security Blog
- Chrome ships device-bound session credentials — Help Net Security
- Google Rolls Out DBSC in Chrome 146 — The Hacker News
- Device Bound Session Credentials — W3C Web Application Security WG
- 2026 CrowdStrike Global Threat Report — CrowdStrike
