Réponse rapide : déployez DBSC là où vous le pouvez. C'est une bonne protection gratuite contre le rejeu de cookies volés sur Chrome. Mais DBSC fait un seul travail précis : il est limité à Chrome, post-connexion, anti-vol plutôt qu'anti-fraude, et conçu selon des principes de confidentialité pour ne vous donner aucune identité d'appareil. L'empreinte d'appareil répond à une autre question, et DBSC est délibérément construit pour ne pas y répondre. Traiter DBSC comme un remplacement de l'empreinte est une erreur de catégorie.
Les Device Bound Session Credentials (DBSC) de Google sont passés en disponibilité générale dans Chrome 146 sur Windows le 2026-04-10. Dès leur lancement, une question légitime s'est posée à chaque équipe fraude et sécurité : si Chrome lie désormais les sessions à l'appareil gratuitement, pourquoi payer encore pour l'empreinte ?
La réponse honnête commence par une concession. Pour son unique travail, DBSC est réellement solide, plus solide qu'une empreinte. Le reste de cet article porte sur tout ce que ce travail n'inclut pas.
Ce qu'est DBSC, maintenant qu'il est en disponibilité générale
DBSC lie une session à une clé privée stockée dans le matériel sécurisé de l'appareil, un TPM sous Windows ou la Secure Enclave sous macOS. La clé ne peut pas être exportée. Environ toutes les cinq minutes, le navigateur prouve qu'il détient toujours cette clé, et le serveur ne renouvelle alors qu'un cookie de courte durée. Volez le cookie et déplacez-le sur une autre machine, et il meurt, car le voleur ne peut pas reproduire la preuve liée au matériel.
Cela ferme exactement la fenêtre de rejeu qu'exploitent à grande échelle les malwares infostealer et les kits de hameçonnage adversaire-au-milieu. Pour comprendre en profondeur pourquoi la session du navigateur est devenue un plan de contrôle, voyez la session du navigateur est désormais un plan de contrôle de sécurité.
Là où DBSC est réellement meilleur
Pour rendre un cookie volé inutile sur un autre appareil, la liaison cryptographique matérielle surpasse une empreinte, et il faut le dire clairement.
Une empreinte est un signal observable. Un attaquant déterminé sur un appareil similaire peut en imiter suffisamment pour passer pour la victime. Lors de nos propres tests, les défenses anti-bots fondées sur l'empreinte invalident durement le rejeu automatisé mais restent molles face à un attaquant humain rejouant un cookie volé depuis un appareil similaire. Une clé privée liée au TPM n'a pas ce point faible : elle ne peut pas être extraite, donc le rejeu échoue tout simplement.
Donc cside ne prétend pas être meilleur pour arrêter le vol de cookies. Pour cette tranche, il ne l'est pas. Concédez le point, puis montez d'un niveau, car c'est au niveau supérieur que vit l'essentiel de la fraude.
DBSC face à l'empreinte d'appareil en un coup d'œil
| Attaque ou besoin | DBSC | Empreinte d'appareil (cside) |
|---|---|---|
| Cookie volé rejoué hors de l'appareil | Forte : la clé matérielle ne peut pas être reproduite | Partielle : détecte le changement d'appareil, peut être imitée |
| Vol d'identifiants et hameçonnage | Aucune : lie aussi l'appareil de l'attaquant | Signale des identifiants valides sur un appareil neuf |
| Credential stuffing | Aucune : agit après la connexion | Détecte les schémas automatisés et d'appareil répété |
| Fraude aux comptes neufs et synthétiques | Aucune : aucune session n'existe encore | Fonctionne à l'inscription |
| Inscriptions de bots, scraping, carding | Aucune | Cas d'usage central, avant authentification |
| Entre comptes et multicompte | Aucune : les clés sont non corrélables par conception | Relie les appareils entre comptes |
| Réputation d'appareil et score de risque | Aucune | Oui |
| Couverture des navigateurs | Chrome sur Windows aujourd'hui | Tous les navigateurs, chaque visiteur |
| Déploiement | Réarchitecture de la session côté serveur | Intégration directe sur le chemin du script de première partie |
| Visibilité pour les attaquants | Protocole public et détectable | Structurellement invisible sur le chemin de première partie |
Pourquoi vous avez toujours besoin de l'empreinte d'appareil
DBSC lie quiconque se connecte, y compris l'attaquant
C'est le point le plus important. DBSC défend contre le vol de cookies, où un malware s'empare d'une session qui appartient déjà à la victime. Il ne fait rien contre le vol d'identifiants, le hameçonnage ou le credential stuffing. Si un attaquant a le mot de passe, DBSC lui délivre volontiers une session propre, liée à son appareil. La liaison est réelle. Elle est simplement liée à la mauvaise personne.
L'empreinte est ce qui détecte la vraie voie du piratage de compte : des identifiants valides arrivant d'un appareil neuf. DBSC bénit précisément le cas que l'empreinte est conçue pour signaler. Pour toute la chaîne d'attaque, voyez comparer les solutions de prévention du piratage de compte.
DBSC ne fonctionne qu'après la connexion
La fraude se produit avant qu'il y ait une session à lier. La fraude aux nouveaux comptes, les identités synthétiques, les inscriptions de bots, les tentatives de credential stuffing, le scraping, le carding et l'abus de bonus sont tous des événements avant authentification ou entre comptes. Il n'y a pas encore d'identifiant de session à lier cryptographiquement, donc DBSC n'a rien sur quoi agir.
L'empreinte fonctionne à l'inscription, à la connexion, au paiement et à la réinitialisation du mot de passe, les moments où se décide l'abus avant authentification.
DBSC est conçu pour ne pas être une couche d'identité d'appareil
C'est une caractéristique, pas une lacune, et il faut bien le comprendre. Les clés DBSC sont par session, par origine et délibérément non corrélables, précisément pour que le mécanisme ne puisse pas devenir un vecteur de suivi ou de liaison. C'est bon pour les utilisateurs.
C'est aussi un mur dur pour les équipes fraude. DBSC vous dira « même navigateur qu'au début de la session, oui ou non », et rien d'autre. Pas de réputation d'appareil. Pas de « cet appareil est derrière 50 comptes ». Pas de liaison entre comptes. Pas de score de risque. Même là où DBSC est pleinement déployé, vous avez toujours besoin d'une couche d'identification d'appareil distincte, car DBSC refuse d'en être une.
Couverture : Chrome sur Windows aujourd'hui
DBSC est en disponibilité générale dans Chrome sur Windows. Le support de macOS via la Secure Enclave reste à venir. Edge a mené un essai d'origine sans disponibilité générale. Safari et Firefox ne le déploient pas. Sur iOS Safari et sur Firefox, c'est zéro protection.
L'empreinte cside fonctionne sur tous les navigateurs, pour chaque visiteur, sans échantillonnage. Elle voit la vraie requête sur le vrai chemin, quel que soit ce que chaque éditeur lancera ensuite.
La réalité du déploiement
DBSC n'est pas un interrupteur. Chaque site doit réarchitecturer sa couche de session côté serveur : enregistrement des clés, points de rafraîchissement, gestion du cycle de vie et solutions de repli pour les navigateurs non pris en charge. C'est pourquoi, un trimestre après la disponibilité générale, la liste publique des parties utilisatrices se résume essentiellement à Google et Okta.
L'empreinte cside est une intégration directe sur le chemin JavaScript de première partie existant. Le délai se compte en semaines, pas en programme de sécurité de plusieurs trimestres.
La différence architecturale : première partie, sans échantillonnage, invisible pour les attaquants
cside collecte via le proxy de première partie sur le chemin de livraison du script. Deux choses en découlent.
C'est sans échantillonnage et universel. Chaque visiteur réel, sur la charge utile réelle livrée aux utilisateurs réels, pas une tranche échantillonnée d'un SDK qu'une partie du trafic ne charge jamais.
C'est structurellement invisible pour les attaquants. Aucune origine de SDK tiers à repérer ni requête distincte à bloquer. Quand nous avons testé de grandes banques et compagnies d'assurance américaines, leur identification d'appareil s'exécutait en première partie et restait invisible pour BuiltWith, Wappalyzer et les scans statiques standards. Seul un rendu réel dans le navigateur la révélait.
DBSC est l'inverse par conception : un protocole public, bien documenté et détectable. Un attaquant peut voir exactement quand DBSC est en jeu et contourner les cas qu'il ne couvre pas, une session Safari, un flux avant connexion ou une session fraîchement obtenue par hameçonnage sur son propre appareil.
Le contrôle du fournisseur
« Utilisez simplement la fonctionnalité de Google » revient à externaliser votre feuille de route de confiance de session vers les choix de conception de Chrome et vers des navigateurs que vous ne contrôlez pas. La couverture, le modèle de confidentialité et le calendrier de déploiement se décident ailleurs. Une couche indépendante du navigateur que vous possédez garde ce contrôle en interne.
La bonne façon d'utiliser DBSC et l'empreinte ensemble
La position crédible est complémentaire, pas exclusive.
Déployez DBSC là où vous le pouvez. C'est une bonne protection gratuite contre le vol de cookies sur Chrome, et elle porte un signal plus large : toute l'industrie se dirige vers la confiance liée à l'appareil. Cela valide la thèse et tend à élargir le budget qui lui est consacré.
Couvrez ensuite ce que DBSC ne peut structurellement pas : tous les navigateurs, de l'avant-connexion au paiement, la fraude entre comptes, l'abus de bots et d'agents IA, la détection de VPN et de proxy et les preuves de rétrofacturation. Le passage de DBSC en disponibilité générale ne comble pas cet écart. Il renforce l'argument pour le combler.
Que faire cette semaine
- Activez DBSC là où votre infrastructure et les navigateurs de vos utilisateurs le prennent en charge. Traitez-le comme une protection gratuite contre le vol de cookies pour Chrome sur Windows, pas comme votre stratégie de confiance de session.
- Ajoutez une couche d'appareil indépendante du navigateur qui s'exécute avant la connexion et entre les comptes, pour que la fraude à l'inscription, le credential stuffing et le piratage depuis un appareil neuf soient visibles sur tous les navigateurs.
- Reliez une non-concordance d'appareil à une action. Une empreinte qui ne correspond pas à la base établie à la connexion devrait déclencher une authentification renforcée ou mettre fin à la session, pas seulement enregistrer une ligne.
- Vérifiez votre couverture hors Chrome. Si les utilisateurs d'iOS Safari et de Firefox n'ont aucune validation de session consciente de l'appareil, c'est là qu'atterrira le prochain rejeu.
Comment cside s'intègre
L'empreinte d'appareil de cside collecte plus de 100 signaux de navigateur, d'appareil et de réseau sur le chemin de première partie pour construire un identifiant persistant de chaque visiteur, dans chaque navigateur. Elle fonctionne avant qu'il y ait une session à lier, relie les appareils entre comptes, score le risque et transmet une non-concordance à votre moteur de règles ou fournisseur d'identité existant.
DBSC vous dit si le cookie est revenu du même appareil. cside vous dit qui est l'appareil, ce qu'il a fait sur vos comptes et s'il faut lui faire confiance, de la première requête jusqu'au paiement.
À la date du 2026-06-09. La disponibilité de DBSC et le support des navigateurs évoluent rapidement ; vérifiez l'état actuel du déploiement auprès des sources de Google et des éditeurs de navigateurs avant de compter sur la couverture.
Demandez une démo pour voir comment cside couvre la fraude que DBSC n'a jamais été conçu pour arrêter.
