Les Device Bound Session Credentials (DBSC) expliqués

Livre blanc Passkey entreprise. Conseils pratiques, modèles de déploiement et KPIs pour les programmes passkeys.

Obtenir le livre blanc

État de la prise en charge par les navigateurs

Légende : ✅ Généralement disponible | 🚧 Annoncé / en développement | ⏸️ Fin de la phase d'essai | 🔄 En cours d'évaluation/surveillance | ❌ Pas encore disponible

Remarque : DBSC est en disponibilité générale (GA) sur Windows avec TPM à partir de Chrome 146 (avril 2026). La prise en charge de macOS via la Secure Enclave est la prochaine étape de déploiement. La feuille de route publiée par Google inclut également des clés basées sur logiciel afin d'étendre la protection aux appareils dépourvus de matériel sécurisé dédié.

Principaux avantages : DBSC vs Modèle actuel

L'architecture du World Wide Web a été fondée sur un principe d'absence d'état (statelessness). Lors de sa conception initiale, HTTP ne conservait aucune information sur les utilisateurs entre les requêtes. Pour remédier à cela, le « cookie » a été inventé : un petit élément de donnée envoyé par un site web et stocké sur l'ordinateur de l'utilisateur, destiné à être renvoyé au site web lors de chaque requête ultérieure. Pendant des décennies, ce mécanisme a servi de socle à la gestion des sessions. Lorsqu'un utilisateur se connecte, le serveur valide ses identifiants et émet un cookie. Ce cookie agit comme un « jeton au porteur ». Dans le monde physique, un instrument au porteur est un document qui confère à son détenteur les droits ou les actifs qu'il représente ; si vous détenez l'obligation, vous la possédez. De même, dans le monde numérique de HTTP, si vous possédez le cookie, vous êtes l'utilisateur.

Cette capacité de jeton au porteur est à la fois la plus grande utilité du web et sa plus profonde vulnérabilité. La sécurité de l'ensemble de la session, et par extension de l'identité, des données et des actifs financiers de l'utilisateur, repose entièrement sur le secret de cette chaîne de cookie. Si un acteur malveillant parvient à copier cette chaîne, il peut se faire passer pour l'utilisateur depuis n'importe quel appareil, n'importe où dans le monde, en contournant entièrement les vérifications d'authentification initiales. Cette vulnérabilité spécifique a donné naissance à une économie souterraine à l'échelle industrielle de « vol de cookies » et de « détournement de session ».

Alors que l'industrie parvient à renforcer la « porte d'entrée » de l'authentification grâce à l'adoption des normes FIDO (Fast Identity Online) et des clés d'accès (passkeys), les attaquants tournent leur attention vers la « porte de derrière » : la session active. L'hameçonnage d'un mot de passe devient de plus en plus difficile, mais le vol d'un cookie de session reste dangereusement efficace. La réponse de l'industrie à cette menace grandissante est Device Bound Session Credentials (DBSC).

DBSC représente un changement de paradigme dans la façon dont les sessions web sont maintenues. Il propose de s'éloigner des simples jetons au porteur pour évoluer vers un modèle où la session est cryptographiquement liée à l'appareil. Avec Chrome 146 (avril 2026) qui intègre DBSC en disponibilité générale sur Windows, la norme est passée du stade expérimental à une capacité de production que les équipes web peuvent déployer dès aujourd'hui. Chrome utilise des TPM sur Windows et déploie ensuite la prise en charge de la Secure Enclave sur macOS ; la spécification elle-même est agnostique quant au stockage des clés, exigeant seulement qu'il soit « robuste face à la menace décrite ». Cela rend les cookies volés beaucoup moins précieux. Ils ne peuvent pas être actualisés depuis un autre appareil sans la clé liée.

Cet article propose une analyse exhaustive de DBSC, conçue pour les architectes de sécurité, les chefs de produit et les développeurs. Il explore l'architecture technique, les implications commerciales d'une « sécurité sans friction », la relation avec les normes émergentes telles que Shared Signals (CAEP/RISC), et la manière dont les organisations peuvent se préparer à cet avenir en utilisant des plateformes comme Corbado.

Questions clés auxquelles cet article répond

1. Pourquoi la gestion de session actuelle échoue-elle à empêcher les prises de contrôle de compte ?
2. En quoi DBSC diffère-t-il des cookies « sécurisés » actuels et des drapeaux HttpOnly ?
3. Comment DBSC et les clés d'accès fonctionnent-ils ensemble pour offrir une meilleure résistance à l'hameçonnage ?
4. Qu'est-il arrivé au Token Binding, et pourquoi DBSC réussit-il là où il a échoué ?
5. Quelles sont les implications commerciales et le ROI pour les chefs de produit ?
6. Quels navigateurs et systèmes d'exploitation prennent en charge DBSC aujourd'hui ?
7. Comment les organisations peuvent-elles implémenter DBSC sans partir de zéro ?
8. Quelle est la relation entre DBSC, DPoP et OAuth 2.0 ?
9. Comment DBSC s'intègre-t-il à Shared Signals (CAEP/RISC) pour une réponse aux menaces en temps réel ?

Pour naviguer dans la complexité de cette nouvelle norme, nous devons d'abord comprendre les problèmes fondamentaux de la gestion de session actuelle et comment DBSC y remédie. Chacun de ces domaines représente une vulnérabilité ou une limitation critique que DBSC résout.

L'échec fondamental de la gestion de session actuelle réside dans la « portabilité » de la confiance. Lorsqu'un serveur émet un cookie de session, il émet essentiellement un passeport qui fonctionne pour quiconque le détient. Bien que les navigateurs aient implémenté des défenses telles que les drapeaux HttpOnly et Secure (empêchant l'accès via JavaScript et garantissant la transmission sur HTTPS), ces défenses ne protègent que contre des vecteurs d'extraction spécifiques tels que le Cross-Site Scripting (XSS) ou l'écoute du réseau. Elles n'offrent aucune protection contre les logiciels malveillants s'exécutant sur l'appareil hôte. Les « infostealers » (voleurs d'informations) sont des logiciels malveillants spécifiquement conçus pour localiser le fichier de stockage de cookies du navigateur sur le disque, le décrypter (souvent en utilisant les propres identifiants de niveau système d'exploitation de l'utilisateur), et exfiltrer le contenu vers un serveur de commande et de contrôle. Une fois que l'attaquant possède le cookie, il peut effectuer une attaque Pass-the-Cookie, injectant le jeton volé dans son propre navigateur pour détourner la session. Le serveur, voyant un cookie valide, suppose que la requête est légitime.

DBSC introduit un deuxième facteur d'authentification dans la boucle même de maintenance de la session. Contrairement à un cookie sécurisé standard, qui est un secret statique, une session DBSC se compose d'un jeton au porteur de courte durée et d'une preuve cryptographique de possession. Le navigateur génère une paire de clés publique-privée stockée de manière sécurisée sur l'appareil. Le serveur lie la session à la clé publique. Périodiquement, le navigateur doit prouver qu'il détient toujours la clé privée en signant un défi émis par le serveur. La spécification exige un stockage des clés « robuste face à la menace décrite ». Chrome utilise le TPM sur Windows lorsqu'il est disponible. Si un attaquant vole le cookie depuis un autre appareil, il ne peut pas l'actualiser car il ne peut pas générer la signature cryptographique requise. L'aspect « porteur » est réduit à une fenêtre très courte, tandis que l'aspect « liaison » assure une continuité à long terme.

Les clés d'accès et DBSC sont des technologies complémentaires qui sécurisent différentes phases du cycle de vie de l'utilisateur. Les clés d'accès (FIDO2) résolvent le problème de l'authentification — prouvant l'identité pour démarrer une session sans mots de passe, éliminant ainsi l'hameçonnage d'identifiants. DBSC aborde le problème de la post-authentification — rendant le détournement de session via le vol de cookies considérablement plus difficile. L'Alliance FIDO présente DBSC comme une technologie complémentaire qui « élève le niveau » contre le détournement de session. Ensemble, ils réduisent la surface d'attaque sur l'ensemble du cycle de vie de connexion et de session — bien que DBSC ne protège pas contre les logiciels malveillants ayant un accès continu à l'appareil ou les attaques de type navigateur de l'homme du milieu (browser-in-the-middle) en temps réel sur le même appareil.

Comment les clés d'accès et DBSC fonctionnent ensemble

DBSC n'est pas la première tentative pour résoudre ce problème. Le « Token Binding » était une norme précédente qui tentait de lier les cookies à la connexion TLS (Transport Layer Security) sous-jacente. Bien que cryptographiquement solide, le Token Binding n'a pas réussi à s'imposer en raison de sa forte dépendance à la couche TLS. Dans le web moderne, les connexions TLS sont souvent terminées au niveau des équilibreurs de charge, des CDN ou des proxys inverses, tandis que la logique applicative réside sur les serveurs situés derrière eux. La propagation des informations de Token Binding à travers ces couches réseau complexes s'est avérée trop difficile. DBSC tire les leçons de cet échec en fonctionnant entièrement au niveau de la couche d'application (HTTP). Il ne dépend pas de la connexion réseau sous-jacente, ce qui le rend compatible avec les équilibreurs de charge, proxys et infrastructures cloud existants.

Pour les responsables de produits, DBSC offre l'opportunité d'améliorer la sécurité tout en améliorant simultanément l'expérience utilisateur (UX). Historiquement, une haute sécurité impliquait des délais d'expiration de session courts, obligeant les utilisateurs à se connecter fréquemment (friction). En liant la session à l'appareil, le risque de vol de cookies à distance est considérablement réduit. Les entreprises peuvent envisager des durées de session plus longues, sachant que les cookies volés ne peuvent pas être actualisés depuis un autre appareil. Cependant, DBSC ne protège pas contre le vol de l'appareil, les logiciels malveillants persistants sur l'appareil ou l'abus par un utilisateur malveillant, de sorte que les politiques de durée de vie de session doivent toujours refléter ces risques résiduels.

Pour comprendre l'urgence de DBSC, il faut apprécier la sophistication du paysage des menaces modernes. Le vol de cookies de session est passé d'une astuce de hacker de niche à une industrie automatisée et évolutive.

graph TD
    A[L'utilisateur télécharge<br/>un logiciel malveillant] -->|Exécution| B[L'Infostealer s'active<br/>sur l'appareil]
    B --> C[Localise les données du navigateur]
    C --> D[Stockage des cookies<br/>Chrome/Edge/Firefox]
    C --> E[Base de données des mots de passe]
    C --> F[Portefeuilles de cryptomonnaies]

    D --> G[Décrypte à l'aide des<br/>identifiants du système d'exploitation]
    E --> G
    F --> G

    G --> H[Crée un fichier journal (log)<br/>avec les données volées]
    H --> I[Exfiltre vers le serveur C2]
    I --> J[Place de marché du Dark Web]

    J --> K[L'attaquant achète le journal]
    K --> L[Importe le cookie dans<br/>son propre navigateur]
    L --> M[Contourne la MFA]
    M --> N[Prise de contrôle<br/>de compte terminée]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

Le Malware-as-a-Service (MaaS) a abaissé la barrière à l'entrée pour les cybercriminels. Les « Infostealers » tels que RedLine, Raccoon, Vidar et Taurus sont des souches de logiciels malveillants disponibles dans le commerce, conçues avec un objectif principal : l'exfiltration de données à partir des navigateurs web. Ces voleurs sont distribués via des e-mails d'hameçonnage, des logiciels piratés ou des publicités malveillantes. Une fois installés, ils ciblent les chemins de fichiers spécifiques où les navigateurs comme Chrome, Edge et Firefox stockent leurs données.

• La cible : La base de données des cookies (généralement un fichier SQLite) et la base de données Login Data (mots de passe enregistrés).
• Le mécanisme : Les navigateurs chiffrent ces bases de données à l'aide d'API de protection des données (DPAPI sur Windows) liées à la session du système d'exploitation de l'utilisateur. Puisque le logiciel malveillant s'exécute en tant qu'utilisateur, il peut très facilement demander le décryptage de ces fichiers.
• Le résultat : Le logiciel malveillant génère un « journal » (log) — un fichier zip contenant les cookies décryptés, les mots de passe, les informations système et parfois les clés des portefeuilles de cryptomonnaies.

Ces journaux sont agrégés et vendus sur les places de marché du dark web telles que Genesis Market (avant son démantèlement) et Russian Market. Les acheteurs peuvent rechercher des journaux contenant des cookies actifs pour des cibles spécifiques de grande valeur : « Salesforce », « Gmail », « Bank of America » ou « AWS Console ».

Le contournement : La valeur d'un journal de cookies réside dans sa capacité à contourner l'authentification multifacteur (MFA). La plupart des défis MFA (SMS, TOTP, Push) n'interviennent que lors de l'événement de connexion. Une fois la session établie et le cookie émis, le serveur suppose que l'utilisateur est digne de confiance. Un attaquant important un cookie de session valide passe directement au travers de la barrière MFA, apparaissant au serveur comme l'utilisateur revenant sur un onglet actif.

Les suites de productivité cloud sont des cibles de choix. Un cookie de session volé pour un compte Google Workspace ou Microsoft Entra ID (anciennement Azure AD) peut donner à un attaquant accès à la messagerie d'entreprise, aux documents et aux systèmes internes. Les propres renseignements sur les menaces de Google ont fait état d'une augmentation massive du vol de cookies comme vecteur principal d'accès aux comptes Google, le désignant explicitement comme le moteur de leur investissement dans DBSC. Ils notent qu'à mesure qu'ils imposent la validation en deux étapes (2SV) et les clés d'accès, les attaquants ont simplement modifié leur tactique, passant de l'hameçonnage d'identifiants (que la 2SV / les clés d'accès bloquent) au vol de cookies (que la 2SV / les clés d'accès ne bloquent souvent pas).

Historiquement, les moteurs de risque ont tenté de détecter le vol de session en analysant les empreintes numériques des appareils, en examinant la chaîne User-Agent, la résolution de l'écran, les polices installées et l'adresse IP. Si un cookie de session apparaît soudainement depuis une nouvelle adresse IP avec une empreinte canvas légèrement différente, le serveur pourrait l'invalider. Le problème : Les initiatives en matière de confidentialité dans les navigateurs (comme l'Intelligent Tracking Prevention de Safari et la Privacy Sandbox de Chrome) réduisent activement l'entropie de ces empreintes numériques pour empêcher le suivi publicitaire. Cela rend la « bonne » prise d'empreinte pour la sécurité de plus en plus difficile. De plus, les attaquants utilisent désormais des « navigateurs anti-détection » qui leur permettent d'usurper parfaitement ces empreintes pour correspondre au profil de la victime, rendant la détection heuristique inefficace. DBSC remplace ce jeu de devinettes probabiliste par une preuve cryptographique déterministe.

Device Bound Session Credentials (DBSC) introduit une API et un protocole normalisés pour la création de sessions liées à une clé sur l'appareil client. La spécification exige un stockage des clés « robuste face à la menace décrite » mais reste agnostique quant à son implémentation. Chrome utilise le TPM sur Windows lorsqu'il est disponible. Cette section détaille les mécanismes tels que définis dans le projet de travail du W3C et la documentation de Chrome.

Le cycle de vie DBSC permet une transition fluide d'une session standard à une session liée, garantissant la rétrocompatibilité et une amélioration progressive.

sequenceDiagram
    participant User as Utilisateur
    participant Browser as Navigateur
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server as Serveur

    Note over User,Server: Phase 1 : Authentification et Liaison
    User->>Browser: Connexion avec identifiants/clé d'accès
    Browser->>Server: Requête d'authentification
    Server->>Browser: Succès + en-tête d'enregistrement DBSC
    Browser->>HSM: Génération de la paire de clés
    HSM->>Browser: Clé publique/privée (privée non exportable)
    Browser->>Server: Enregistrement de la clé publique (JWT signé)
    Server->>Server: Liaison de la session à la clé publique
    Server->>Browser: Cookie de courte durée (5 min)

    Note over User,Server: Phase 2 : Utilisation normale
    loop Chaque requête pendant 5 minutes
        Browser->>Server: Requête avec cookie
        Server->>Browser: Réponse
    end

    Note over User,Server: Phase 3 : Actualisation (après expiration)
    Browser->>Server: Requête avec cookie expiré
    Server->>Browser: 401 + Défi (nonce)
    Browser->>HSM: Signer le défi
    HSM->>Browser: Signature
    Browser->>Server: Preuve de signature
    Server->>Server: Vérification avec la clé publique stockée
    Server->>Browser: Nouveau cookie de courte durée
    Browser->>Server: Nouvelle tentative de la requête d'origine
    Server->>Browser: Réponse de succès

Le processus de liaison commence immédiatement après que l'utilisateur s'est authentifié à l'aide des méthodes standard (mot de passe, clé d'accès, etc.).

1. Signal du serveur : Lors d'une connexion réussie, le serveur définit un cookie de session (comme d'habitude) mais ajoute un en-tête spécifique indiquant la prise en charge de DBSC.

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • L'en-tête Secure-Session-Registration dit au navigateur : « Je prends en charge les algorithmes ES256 et RS256. Veuillez enregistrer une session liée au point de terminaison /auth/dbsc/register. »

2. Génération de clé : Le navigateur analyse cet en-tête. Il génère une nouvelle paire de clés asymétriques (par exemple, Elliptic Curve P-256), stockée de manière sécurisée sur l'appareil.

   • Note d'implémentation : Chrome utilise le TPM sur Windows lorsqu'il est disponible ; la spécification est agnostique quant au mécanisme de stockage, exigeant seulement qu'il soit « robuste face à la menace décrite ».
   • Portée de la confidentialité : La clé est limitée à l'origine web (par exemple, banque.com). Le navigateur s'assure que cette clé n'est jamais utilisée pour commercant.com, ce qui empêche le suivi intersites (cross-site tracking).

3. Requête d'enregistrement : Le navigateur envoie une requête au chemin d'enregistrement spécifié. Cette requête inclut la Clé Publique nouvellement générée à l'intérieur d'un JSON Web Token (JWT), signé par la Clé Privée (attestation auto-signée).

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<En-tête JWT\>.\<Charge utile JWT contenant la Clé Publique\>.\<Signature\>
   

4. Liaison de session : Le serveur valide la signature pour s'assurer que la clé publique est fonctionnelle. Il met ensuite à jour sa base de données pour associer la session de l'utilisateur (session_id=xyz123) à cette Clé Publique spécifique. À partir de ce moment, la session est « liée ».

Afin de trouver un équilibre entre sécurité et performances (les opérations de clé sécurisées peuvent ajouter de la latence), DBSC utilise un système à double jeton.

1. Émission : Le serveur émet un nouveau cookie de courte durée (par exemple, valide pour 5 minutes). Appelons-le access_token.
2. Utilisation : Le navigateur utilise cet access_token pour toutes les requêtes normales (récupération d'images, appels API, navigation dans les pages). Tant que le cookie est valide, aucune opération cryptographique n'est effectuée. Cela garantit que la navigation reste rapide.
3. Expiration : Après 5 minutes, l'access_token expire.

C'est le cœur du mécanisme de sécurité. Lorsque le cookie de courte durée expire, un attaquant sur un autre appareil se retrouve bloqué, mais l'utilisateur légitime (ayant accès à la clé liée) peut continuer.

1. Détection : Le navigateur tente une requête. Il remarque que le cookie est expiré (ou le serveur renvoie un 401 ou un en-tête Secure-Session-Challenge spécifique).
2. Interception : Le navigateur suspend la requête réseau. Il ne montre pas d'erreur à l'utilisateur.
3. Requête d'actualisation : Le navigateur appelle automatiquement le point de terminaison d'actualisation défini dans la configuration de session.
   • Le serveur envoie un Défi cryptographique (un nonce).
   • Le navigateur utilise la clé liée pour signer ce défi.
   • La signature prouve la possession de la clé privée.
4. Soumission : Le navigateur renvoie le défi signé au serveur.

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<ID de Session\>
   Secure-Session-Response: \<Signature JWT du Défi\>
   

5. Validation : Le serveur utilise la Clé Publique stockée pour vérifier la signature.
   • Si Valide : Le serveur sait que la requête provient du même appareil physique que celui qui a démarré la session. Il émet un nouveau access_token de courte durée (valide pour 5 minutes supplémentaires).
   • Si Invalide : La requête est rejetée. La session est interrompue.
6. Reprise : Le navigateur prend le nouveau cookie et réessaie de manière transparente la requête d'origine mise en pause. L'utilisateur ne subit aucune interruption.

graph LR
    subgraph "Appareil de la victime"
        A[Session utilisateur<br/>avec DBSC]
        B[Clé Privée<br/>HSM/TPM]
        C[Cookie +<br/>ID de Session]
        A --> B
        A --> C
        B -.->|Non exportable| X[Impossible d'extraire<br/>la Clé Privée]
    end

    subgraph "Scénario d'attaque"
        D[RedLine Stealer<br/>infecte l'appareil]
        D --> E[Vole le Cookie<br/>et l'ID de Session]
        E --> F[Exporte vers<br/>l'attaquant]
    end

    subgraph "Appareil de l'attaquant"
        G[Importe le cookie<br/>volé]
        H[Tente d'utiliser<br/>la session]
        I[Le serveur demande<br/>l'actualisation DBSC]
        J[Impossible de signer<br/>le défi]
        K[Session refusée]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|Volé| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

Considérons un attaquant qui infecte le PC de l'utilisateur avec RedLine Stealer. Il vole l'access_token et le session_id. Il les importe dans son propre navigateur.

• Scénario A (Dans les 5 minutes) : L'attaquant pourrait obtenir un accès pendant quelques minutes jusqu'à ce que le jeton de courte durée expire.
• Scénario B (Après expiration) : Le navigateur de l'attaquant (sur un autre appareil) essaie d'utiliser le jeton. Le serveur le rejette et demande une actualisation. Le navigateur de l'attaquant voit les en-têtes DBSC mais ne peut pas effectuer l'actualisation car il ne possède pas la clé privée liée. L'attaque échoue.

La confidentialité est un objectif de conception central de DBSC. La spécification W3C interdit explicitement l'utilisation d'identifiants globaux qui pourraient suivre les utilisateurs à travers les sites.

• Clés par origine : Le navigateur génère une paire de clés unique pour chaque site. google.com voit la Clé A ; amazon.com voit la Clé B. Il n'y a aucune corrélation entre elles.
• Effacement par l'utilisateur : Si l'utilisateur efface ses cookies/données de site, le navigateur supprime également les clés DBSC associées. Cela garantit que DBSC ne peut pas être utilisé comme un « super-cookie » pour ressusciter des identités supprimées.

L'implémentation de DBSC nécessite que le serveur conserve un état concernant les clés publiques.

• Schéma de base de données : La table de session doit être mise à jour pour stocker la public_key et le last_challenge aux côtés du user_id et de la session_expiry.
• Performances : L'opération d'actualisation implique une vérification cryptographique (par exemple, la vérification d'une signature ECDSA). Bien que rapide, elle est plus gourmande en ressources processeur que la vérification d'une simple chaîne. Cependant, comme les actualisations ne se produisent que toutes les quelques minutes (et non à chaque requête), le surcoût est négligeable.

Au-delà des spécifications techniques, DBSC comporte d'importantes implications pour la stratégie commerciale, les feuilles de route des produits et les postures de conformité.

Les initiatives de sécurité sont souvent considérées comme des centres de coûts ou des générateurs de friction. DBSC renverse ce récit. Le diagramme suivant illustre la façon dont la liaison à l'appareil crée une cascade d'avantages commerciaux :

• Réduction de la fraude : En neutralisant le principal vecteur de prise de contrôle de compte (ATO), les entreprises peuvent économiser des millions en pertes dues à la fraude.
• Coûts d'assistance : La récupération de compte est onéreuse. Empêcher le piratage en premier lieu réduit directement cette charge opérationnelle.
• Optimisation de la conversion : Dans le commerce électronique, chaque invite de connexion est un point d'abandon potentiel. DBSC permet des politiques agressives de « maintenir la connexion », rendant possible le paiement instantané sans invites de mot de passe.

Les cadres réglementaires tels que le RGPD en Europe obligent les organisations à mettre en œuvre « des mesures techniques et organisationnelles appropriées » pour garantir la sécurité.

• Sécurité défendable : À mesure que DBSC devient une norme, il sera probablement interprété comme « l'état de l'art » en matière de gestion de session. En cas de violation, démontrer que DBSC a été mis en œuvre peut être une défense puissante contre les allégations de négligence.
• Normes bancaires (DSP2) : La directive sur les services de paiement 2 exige une « authentification forte du client » (SCA). Bien que la SCA se concentre sur la connexion, la liaison dynamique de la session à l'appareil s'aligne parfaitement avec les objectifs de la directive consistant à lier l'authentification à des montants et des bénéficiaires spécifiques.

Les livres blancs de l'Alliance FIDO soulignent le concept de « Niveaux d'assurance ».

• Assurance modérée : Utilise des clés d'accès synchronisées (comme celles du trousseau iCloud). Idéal pour les applications grand public, récupérable, facile à utiliser.
• Haute assurance : Nécessite des clés liées à l'appareil. C'est là que DBSC brille. Pour les ressources d'entreprise (portails RH, référentiels de code) ou les opérations bancaires de grande valeur, l'organisation peut imposer une politique qui n'autorise l'accès qu'à partir de sessions liées à un appareil géré spécifique. DBSC fournit le mécanisme d'application technique pour cette politique.

Pour apprécier pleinement DBSC, nous devons le comparer à d'autres technologies qui ont tenté de résoudre des problèmes similaires.

graph RL
    subgraph "Cookies traditionnels"
        TC1[Jeton au porteur uniquement]
        TC2[Vulnérable au vol]
        TC3[Sessions longues = Risque]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "Token Binding"
        TB1[Liaison couche TLS]
        TB2[❌ Échec : Infrastructure complexe]
        TB3[Casse aux équilibreurs de charge]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[Liaison de jeton OAuth]
        DP2[✅ Protection d'API]
        DP3[Pas pour les sessions de navigateur]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[Liaison couche HTTP]
        D2[✅ Protection clé matérielle]
        D3[✅ Fonctionne avec CDN/LB]
        D4[✅ Sessions de navigateur]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

Comme mentionné, le Token Binding tentait de lier la session à la couche TLS.

• Token Binding : Nécessitait une prise en charge par le client, le serveur, et chaque saut intermédiaire (équilibreurs de charge, terminateurs TLS). Il se brisait lorsqu'une connexion était terminée et rechiffrée.
• DBSC : Fonctionne au niveau de la couche d'application HTTP. Il traverse les équilibreurs de charge de manière transparente comme des en-têtes/cookies standard. Il est beaucoup plus facile à déployer dans les architectures cloud modernes (AWS/GCP/Azure) où le TLS est souvent géré par le réseau périphérique du fournisseur de cloud.

DPoP (RFC 9449) est la norme pour les jetons OAuth « contraints à l'expéditeur ». Il lie à la fois les jetons d'accès et les jetons d'actualisation à une clé publique — ce qui est essentiel puisque les jetons d'actualisation sont eux-mêmes des identifiants au porteur de longue durée. Chaque requête d'API inclut une preuve DPoP : un JWT signé avec la méthode HTTP, l'URL, l'horodatage et un identifiant unique. Les spécifications de haute assurance comme FAPI 2.0 imposent des jetons contraints à l'expéditeur ; DPoP est la méthode recommandée lorsque le mTLS est indisponible.

La différence clé : Les clés DPoP résident dans le contexte de l'application. La meilleure pratique consiste à utiliser les API du système d'exploitation pour un stockage non extractible, mais cela n'est pas imposé : de nombreuses implémentations conservent les clés dans la mémoire accessible par JavaScript. Si un attaquant peut exécuter du code arbitraire (XSS, logiciel malveillant), il peut accéder aux clés DPoP ou générer des preuves à la demande. DPoP empêche le rejeu de jetons entre différents clients, mais ne peut pas protéger un contexte de navigateur compromis.

DBSC déplace la preuve de possession dans le navigateur et le matériel. La clé privée réside dans un TPM ou une enclave sécurisée que JavaScript ne peut ni lire ni exporter. Le navigateur gère le protocole et produit des signatures sans exposer les clés au code de l'application. Même si l'application web est entièrement compromise, un attaquant ne peut pas créer de nouvelles preuves pour des cookies volés sur une autre machine.

Synergie : Comme le note l'Alliance FIDO, les clés d'accès éliminent l'hameçonnage lors de la connexion, tandis que DBSC/DPoP protègent les jetons post-authentification. Une architecture moderne combine les deux : DPoP pour les API OAuth (particulièrement le système bancaire ouvert réglementé), DBSC pour les sessions de navigateur. Ensemble, ils ferment le vecteur d'attaque « lift and shift » sur l'ensemble du cycle de vie de la session.

Le simple fait de raccourcir la durée de vie des cookies (par exemple, à 15 minutes) améliore la sécurité mais détruit l'UX. Les utilisateurs sont obligés de se connecter constamment. DBSC permet effectivement la sécurité d'un cookie de 5 minutes avec l'expérience utilisateur d'un cookie de 30 jours.

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as Outils de Sécurité<br/>(CrowdStrike, Defender)
    participant IdP as Fournisseur d'Identité<br/>(Okta, Google, Azure)
    participant SP1 as Fournisseur de Services 1<br/>(Slack)
    participant SP2 as Fournisseur de Services 2<br/>(Salesforce)
    participant SP3 as Fournisseur de Services 3<br/>(App Bancaire)
    participant Session as Session Utilisateur<br/>(Protégée par DBSC)

    Note over ST,Session: Phase de Détection des Menaces
    ST->>ST: Détecte un logiciel malveillant sur<br/>l'appareil de l'utilisateur
    ST->>IdP: Signal RISC :<br/>« Appareil Compromis »

    Note over IdP,SP3: Phase de Propagation du Signal
    IdP->>SP1: Événement CAEP :<br/>« Appareil Compromis »
    IdP->>SP2: Événement CAEP :<br/>« Appareil Compromis »
    IdP->>SP3: Événement CAEP :<br/>« Appareil Compromis »

    Note over SP1,Session: Phase d'Application (avec DBSC)
    Session->>SP1: Prochaine tentative d'actualisation<br/>(dans quelques minutes)
    SP1-->>Session: x Rejeter la signature
    Session->>SP2: Prochaine tentative d'actualisation
    SP2-->>Session: x Rejeter la signature
    Session->>SP3: Prochaine tentative d'actualisation
    SP3-->>Session: x Rejeter la signature

    Note over Session: Les sessions peuvent être terminées à la prochaine tentative d'actualisation

Le potentiel de DBSC est amplifié lorsqu'il est combiné au Shared Signals Framework (SSF), spécifiquement le Continuous Access Evaluation Profile (CAEP) et le Risk Management (RISC). Remarque : SSF/CAEP est une capacité émergente de l'écosystème : le modèle d'architecture est défini, mais le déploiement multi-fournisseurs à grande échelle est encore en phase de maturation.

Dans l'ancien modèle, si l'appareil d'un utilisateur était compromis, le fournisseur d'identité (IdP) n'avait aucun moyen de dire au fournisseur de services (SP) de tuer la session immédiatement. Le SP devait attendre que le cookie expire.

Le flux envisagé pour DBSC + CAEP :

1. Déclencheur : Un outil de sécurité des terminaux (comme CrowdStrike ou Microsoft Defender) détecte un logiciel malveillant sur l'ordinateur portable de l'utilisateur.
2. Signal : L'outil de sécurité envoie un signal RISC au fournisseur d'identité (par exemple, Okta/Google).
3. Propagation : L'IdP transmet un événement CAEP aux applications connectées : « Appareil compromis ».
4. Application (DBSC) : La prochaine fois que le navigateur essaie d'actualiser le cookie DBSC de courte durée, le serveur rejette la signature et tue la session.
   Ce modèle d'architecture permet une révocation plus rapide — la latence réelle dépend de la période d'actualisation du site et de la question de savoir s'il a implémenté à la fois DBSC et SSF.

L'adoption de DBSC dépend des fournisseurs de navigateurs. Le paysage de 2026 a considérablement évolué : Chrome a fait passer DBSC du statut d'Origin Trial à celui de disponibilité générale sur Windows en avril 2026, avec macOS qui devrait suivre. Les autres navigateurs sont toujours en phase d'évaluation.

Google est le principal moteur de DBSC et le premier navigateur à l'intégrer à grande échelle.

• État (avril 2026) : Chrome 146 intègre DBSC en disponibilité générale sur Windows, mettant fin à la phase d'Origin Trial. La prise en charge de macOS, utilisant la Secure Enclave, est annoncée pour une prochaine version de Chrome.
• Matériel : Windows utilise le TPM, macOS utilisera la Secure Enclave. Google a déclaré qu'il explorait également des clés basées sur logiciel afin d'étendre la protection DBSC aux appareils dépourvus de matériel sécurisé dédié.
• Feuille de route : L'annonce de GA de Google a également publié la feuille de route des prochaines étapes :
  • Sécurisation de l'identité fédérée : liaisons DBSC cross-origin pour que la session de la partie utilisatrice (RP) reste liée à la même clé d'appareil que la session du fournisseur d'identité (IdP), préservant ainsi une chaîne de confiance ininterrompue via SSO.
  • Enregistrement avancé : lier les sessions DBSC à des éléments de clé de confiance préexistants tels que les certificats mTLS ou les clés de sécurité matérielles, au lieu de générer une nouvelle clé lors de la connexion.
  • Prise en charge d'appareils plus larges : clés basées sur logiciel pour les appareils sans TPM / Secure Enclave.
• Résultats opérationnels : Pendant le déploiement, Google a signalé une « réduction significative du vol de session » pour les sessions protégées par DBSC.
• Comptes Google : Séparément, Google avait déjà déployé une protection de style DBSC pour les cookies de compte Google sur Chrome pour Windows, contrôlée via une politique d'entreprise. Cela protège Gmail/Workspace et constitue désormais la même famille de technologies que celle qui est en GA pour le web en général.

Microsoft participe activement.

• État : Edge a mené un Origin Trial DBSC sur Windows qui s'est terminé en octobre 2025. Aucun essai de remplacement ou GA n'a été annoncé.
• Contexte d'entreprise : Edge utilise l'architecture du « Jeton d'actualisation principal » (PRT) pour l'Entra/Azure AD SSO, ce qui est conceptuellement similaire à DBSC. Le PRT reste un mécanisme spécifique à Microsoft ; il n'y a pas de plan annoncé pour l'unifier avec la norme web DBSC pour les sites tiers.

La position d'Apple est critique pour la couverture mobile.

• État : WebKit a un problème de positionnement sur les normes évaluant DBSC avec des préoccupations notées concernant l'utilisabilité et la confidentialité. Les notes de mise à jour de Safari ne mentionnent pas DBSC. Il n'existe aucune déclaration publique « d'implémentation active ».
• La confidentialité avant tout : La principale préoccupation d'Apple est que DBSC puisse être utilisé pour des « super-cookies » (suivi ineffaçable). La spécification du W3C aborde cela en garantissant que les clés sont effacées avec les données du site web.
• Engagement : WebKit participe au processus de normalisation, mais l'état de l'implémentation n'est pas clair — plutôt « en cours de discussion » que « en cours de développement ».

Mozilla a un problème de positionnement sur les normes évaluant DBSC avec des préoccupations notées concernant la complexité et la confidentialité. Il n'y a pas d'engagement public à implémenter une fois que la norme se stabilisera.

Compte tenu de la prise en charge actuelle de l'écosystème pour DBSC et les clés d'accès, les organisations devraient adopter une approche progressive pour mettre en œuvre ces technologies complémentaires. La feuille de route ci-dessous décrit les actions immédiates et les jalons de planification stratégique :

1. Déployer les clés d'accès en premier : Commencez par l'implémentation des clés d'accès pour sécuriser la couche d'authentification. Cela offre une protection immédiate contre l'hameçonnage d'identifiants et constitue le préalable pour tirer une réelle valeur de DBSC.

2. Livrer les points de terminaison d'enregistrement et d'actualisation DBSC : Avec Chrome 146 en GA, le véritable travail est désormais l'intégration backend : ajoutez les en-têtes Secure-Session-Registration sur les réponses de connexion et implémentez /dbsc/register plus un point de terminaison d'actualisation qui vérifie les défis signés. Le code front-end n'a pas besoin de changer.

3. Implémenter des sessions de courte durée avec des jetons d'actualisation : Si vous n'êtes pas encore prêt pour DBSC, adoptez le modèle architectural de jetons de courte durée avec des mécanismes d'actualisation. Cela prépare votre backend pour DBSC tout en améliorant la sécurité dès aujourd'hui.

1. Adopter une approche hybride : Utilisez la détection de fonctionnalités pour proposer DBSC aux navigateurs compatibles (actuellement Chrome 146+ sur Windows, puis la Secure Enclave de macOS) tout en conservant des options de repli. Cela maximise la sécurité sans exclure les utilisateurs sur Safari, Firefox ou Edge.

2. Se préparer pour les prochains éléments de la feuille de route : Google a explicitement évoqué l'identité fédérée (liaisons SSO cross-origin), l'enregistrement avancé (mTLS / clés matérielles) et les clés basées sur logiciel pour une couverture plus large des appareils. Si vous exploitez une couche SSO ou IdP, commencez à définir la portée de la liaison cross-origin dès maintenant.

3. S'intégrer aux fournisseurs d'identité : Si vous utilisez Okta, Auth0 ou des IdP similaires, collaborez avec eux pour activer la prise en charge de DBSC dans leurs SDK. Beaucoup ont participé aux Origin Trials et déploient activement les capacités DBSC maintenant que Chrome est en GA.

• Commencer par des cibles de grande valeur : Donnez la priorité à DBSC pour les panneaux d'administration, les transactions financières et l'accès aux données sensibles.
• Utiliser des solutions gérées : Envisagez des plateformes comme Corbado qui gèrent la complexité de l'implémentation de DBSC et de la compatibilité des navigateurs.
• Mesurer et itérer : Suivez des indicateurs tels que les tentatives de détournement de session, les tickets d'assistance et la friction utilisateur pour démontrer le ROI.
• Se préparer à la conformité : Documentez votre implémentation de DBSC, car elle deviendra probablement une exigence de conformité pour le traitement des données sensibles.

Implémenter DBSC en partant de zéro est une lourde tâche d'ingénierie. Cela nécessite une expertise en cryptographie, une connaissance approfondie des incohérences des navigateurs et une infrastructure robuste côté serveur pour gérer les clés et les défis. C'est là que Corbado agit comme un facilitateur.

Vous ne pouvez pas construire une session à haute assurance sur une connexion à faible assurance. Si un utilisateur se connecte avec un mot de passe faible, la session n'est sécurisée qu'à la hauteur de ce mot de passe. Le produit de base de Corbado (clés d'accès gérées) fournit la base nécessaire. En intégrant Corbado, les organisations peuvent facilement déployer des clés d'accès, s'assurant que le début de la session est résistant à l'hameçonnage.

Corbado s'appuiera sur DBSC pour améliorer la détection d'appareils de confiance. Lorsque les signaux DBSC sont disponibles, ils fournissent la preuve cryptographique qu'une session provient d'un appareil spécifique, permettant à Corbado d'augmenter les niveaux de confiance d'authentification en conséquence.

• Résoudre l'ambiguïté des clés d'accès synchronisées : Les clés d'accès synchronisées sont pratiques mais créent un vide en matière de confiance : lorsqu'un utilisateur s'authentifie avec une clé d'accès synchronisée, vous ne pouvez pas savoir s'il s'agit de son ordinateur portable habituel ou d'un tout nouvel appareil qui vient de synchroniser l'identifiant. DBSC comble ce vide. En vérifiant si l'appareil possède une liaison DBSC établie, Corbado peut vérifier que l'appareil est véritablement connu et digne de confiance, et pas seulement une première synchronisation.
• Une confiance accrue pour les appareils connus : Lorsque les signaux DBSC confirment qu'un appareil a déjà été vu, Corbado peut prendre des décisions de risque plus confiantes : moins d'invites d'authentification renforcée pour les utilisateurs légitimes de retour, un examen plus strict pour les sessions provenant d'appareils non reconnus.
• Compléter l'intelligence des clés d'accès : Les signaux DBSC s'intègrent au moteur existant Passkey Intelligence de Corbado. La combinaison de l'authentification basée sur les clés d'accès et de la liaison d'appareil basée sur DBSC crée une chaîne de confiance complète, de la connexion jusqu'à l'ensemble du cycle de vie de la session.

Pour toute question sur la façon dont Corbado prévoit d'intégrer DBSC à sa plateforme, contactez l'équipe.

Pour les prochaines années, le web sera hybride. Certains utilisateurs auront des navigateurs compatibles avec DBSC (Chrome sur Windows 11) ; d'autres seront sur des systèmes plus anciens. Gérer cette fragmentation est difficile. Le moteur Passkey Intelligence de Corbado est conçu pour gérer exactement ce type de logique de repli en proposant des clés d'accès aux appareils capables et des solutions de repli aux autres. Cette même intelligence s'applique à la liaison de session, garantissant que la sécurité est maximisée pour chaque utilisateur en fonction des capacités de son appareil.

L'ère du « Jeton au porteur » touche à sa fin. La gestion de session actuelle échoue de manière catastrophique — les jetons au porteur peuvent être volés par des opérations de logiciels malveillants à l'échelle industrielle et utilisés depuis n'importe quel appareil, permettant des prises de contrôle de compte qui contournent même les méthodes d'authentification les plus fortes. Cette vulnérabilité fondamentale a créé une économie souterraine qui pèse des milliards.

Device Bound Session Credentials (DBSC) représente la réponse émergente de l'industrie. Contrairement aux cookies sécurisés traditionnels avec leurs drapeaux HttpOnly et leurs secrets statiques, DBSC ajoute une preuve de possession cryptographique via des clés liées à l'appareil. Cela rend les cookies volés beaucoup moins précieux. Ils ne peuvent pas être actualisés depuis un autre appareil. Là où le Token Binding a échoué en nécessitant des modifications complexes de la couche TLS sur l'ensemble de l'infrastructure, DBSC réussit en fonctionnant au niveau de la couche d'application HTTP, compatible avec les équilibreurs de charge et les architectures CDN existantes. Remarque : DBSC a documenté des chemins de repli où le navigateur saute la liaison (TPM indisponible, erreurs réseau), de sorte qu'il réduit considérablement mais n'élimine pas le risque de vol de cookies.

La synergie entre DBSC et les clés d'accès élève considérablement le niveau de difficulté pour les attaquants tout au long du parcours utilisateur. Les clés d'accès éliminent l'hameçonnage d'identifiants lors de la connexion, tandis que DBSC rend le détournement de session via le vol de cookies à distance beaucoup plus difficile — formant ensemble le cadre d'identité à « haute assurance » envisagé par l'Alliance FIDO. Avec Chrome 146 déployant DBSC en disponibilité générale sur Windows en avril 2026 et la prise en charge de la Secure Enclave de macOS prévue ensuite, la norme est passée de la phase de préparation à la phase de déploiement. La feuille de route publiée par Google (identité fédérée, enregistrement mTLS / clé matérielle, clés basées sur logiciel) signale les 12 prochains mois d'expansion.

Pour les chefs de produit, l'argumentaire commercial est convaincant : DBSC permet des sessions sécurisées « infinies » qui réduisent considérablement la friction de connexion tout en diminuant simultanément les pertes dues à la fraude et les coûts d'assistance. Le ROI se manifeste par des taux de conversion plus élevés, moins de tickets de réinitialisation de mot de passe et l'élimination des incidents de prise de contrôle de compte. Les organisations utilisant OAuth peuvent exploiter le même concept de liaison de clé via DPoP pour les jetons d'API, tandis que l'intégration avec Shared Signals (CAEP/RISC) permet une réponse aux menaces en temps réel — révoquant instantanément les sessions compromises lors de la prochaine tentative d'actualisation.

L'implémentation ne nécessite pas de partir de zéro. Des plateformes telles que Corbado fournissent l'infrastructure des clés d'accès et suivent les développements de DBSC pour intégrer la liaison à l'appareil à mesure que la prise en charge par les navigateurs arrive à maturité. La spécification du W3C est un projet de travail actif, Chrome 146 est en GA sur Windows et en cours de déploiement sur macOS, et les autres navigateurs évaluent encore la norme.

La trajectoire est claire : les organisations qui commencent à adopter les clés d'accès et DBSC dès aujourd'hui seront les mieux positionnées pour l'avenir sans mot de passe et résistant à l'hameçonnage. La question n'est pas de savoir s'il faut implémenter des sessions liées à l'appareil, mais à quelle vitesse vous pouvez les déployer pour protéger vos utilisateurs et votre entreprise. L'avenir de la sécurité web n'est pas seulement authentifié ; il est lié de manière cryptographique aux appareils auxquels nous faisons confiance.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

Lorsque des outils de sécurité des terminaux comme CrowdStrike détectent un logiciel malveillant, ils envoient un signal RISC au fournisseur d'identité, qui transmet un événement CAEP « Appareil compromis » aux applications connectées. Lors de la prochaine tentative d'actualisation des DBSC (dans les minutes qui suivent), ces applications rejettent la signature de session et mettent fin à l'accès. Le déploiement multi-fournisseurs de CAEP/RISC est encore en phase de maturation.

DPoP (RFC 9449) lie les jetons d'accès et d'actualisation OAuth à une clé publique au niveau de la couche d'application, protégeant principalement les appels d'API dans les applications natives et les SPA. DBSC lie les cookies de session du navigateur à des clés TPM adossées au matériel que JavaScript ne peut ni lire ni exporter, protégeant ainsi les sessions côté utilisateur même lorsque l'application web elle-même est compromise par un XSS ou un logiciel malveillant.

La conception sécurisée traditionnelle exige des délais d'expiration de session courts afin de limiter les dégâts si un cookie est volé et rejoué à distance. DBSC lie la capacité d'actualisation à la clé privée de l'appareil d'origine, de sorte qu'un cookie volé et utilisé depuis un autre appareil échoue au défi cryptographique. Les sessions peuvent être effectivement indéfinies car les attaques par rejeu à distance sont neutralisées.

DBSC neutralise le vol de cookies en tant que principal vecteur de prise de contrôle de compte (ATO), ce qui réduit directement les pertes dues à la fraude et les coûts d'assistance liés à la récupération des comptes. Les sessions longues sécurisées éliminent les invites de connexion répétées, ce qui améliore les taux de conversion dans le commerce électronique et réduit les abandons. L'Alliance FIDO considère que DBSC élève le niveau de sécurité tout en réduisant la friction pour l'utilisateur.