--- url: 'https://www.corbado.com/fr/blog/device-bound-session-credentials-dbsc' title: 'Les Device Bound Session Credentials (DBSC) expliqués' description: 'Apprenez comment les Device Bound Session Credentials (DBSC) préviennent le détournement de session et le vol de cookies. Découvrez l''état de la prise en charge par les navigateurs et la sécurité en entreprise.' lang: 'fr' author: 'Vincent Delitz' date: '2026-06-15T13:57:08.864Z' lastModified: '2026-06-16T06:05:12.344Z' keywords: 'Device Bound Session Credentials, DBSC, prévention du détournement de session, protection contre le vol de cookies, liaison de session TPM' category: 'Authentication' --- # Les Device Bound Session Credentials (DBSC) expliqués **État de la prise en charge par les navigateurs** > **Dernière mise à jour (avril 2026) :** Chrome 146 intègre > [DBSC en disponibilité générale (GA) sur Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > ce qui fait sortir la fonctionnalité de l'Origin Trial. La prise en charge de macOS (via > la [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) est pré[vue](https://www.corbado.com/blog/vuejs-passkeys) dans > une prochaine version de Chrome. Google a également annoncé une feuille de route > publique pour l'identité fédérée (liaisons [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) > [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)), l'enregistrement avancé (mTLS / clés > matérielles) et les clés basées sur logiciel pour les appareils dépourvus de matériel > sécurisé. | Navigateur | Windows | macOS | Linux | Android | iOS | État | | ----------- | -------------------------- | --------------------------- | ------------------ | ------------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 À venir (Secure Enclave) | ❌ | ❌ | ❌ | [GA sur Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (avril 2026), macOS dans une prochaine version | | **Edge** | ⏸️ Fin de la phase d'essai | ❌ | ❌ | ❌ | ❌ | Fin de l'Origin Trial en octobre 2025, aucune GA annoncée | | **Safari** | N/A | 🔄 En cours d'évaluation | N/A | N/A | 🔄 En cours d'évaluation | Discussions en cours chez WebKit, aucune implémentation annoncée | | **Firefox** | 🔄 En surveillance | 🔄 En surveillance | 🔄 En surveillance | 🔄 En surveillance | 🔄 En surveillance | En cours d'évaluation, aucun engagement d'implémentation | **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](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/glossary/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** | **Fonctionnalité** | **Modèle de cookie actuel** | **Modèle DBSC** | | ------------------------ | ---------------------------------- | ------------------------------------------------------------ | | **Type de jeton** | Porteur (possession = accès) | Lié (possession + clé = accès) | | **Conséquence d'un vol** | Prise de contrôle totale du compte | Jeton inutile (impossible à actualiser) | | **Durée de session** | Courte (pour la sécurité) | Longue / infinie (sécurisé par conception) | | **Friction utilisateur** | Élevée (connexions fréquentes) | Faible (sécurité invisible) | | **Contournement MFA** | Vulnérable (pass-the-cookie) | Résistant (appareil requis) | | **Révocation** | Lente (attente de l'expiration) | Quasiment en temps réel (échec à la prochaine actualisation) | ## Key Facts - **DBSC** lie les sessions web à une clé cryptographique conservée sur l'appareil, rendant les cookies volés inutilisables car ils ne peuvent pas être actualisés depuis un autre appareil. - Le navigateur stocke une clé privée non exportable dans un **TPM**, signant les défis du serveur toutes les 5 minutes pour prouver la possession de l'appareil sans interaction de l'utilisateur. - Contrairement au **Token Binding**, qui a échoué en raison de la complexité de l'infrastructure de la couche TLS, DBSC fonctionne au niveau de la couche d'application HTTP et opère de manière transparente avec les équilibreurs de charge et les CDN existants. - **Chrome 146 déploie DBSC en disponibilité générale (GA) sur Windows (avril 2026)**, la prise en charge de la Secure Enclave de macOS étant prévue dans une prochaine version. La feuille de route publiée par Google couvre également 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 les appareils sans matériel sécurisé. Safari et Firefox sont toujours en phase d'évaluation ; l'Origin Trial d'Edge s'est terminé en octobre 2025 sans annonce de GA. ## 1. Introduction : Les Device Bound Session Credentials (DBSC) expliqués 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) grâce à l'adoption des normes FIDO (Fast Identity Online) et des [clés d'accès](https://www.corbado.com/fr/glossary/cda) (passkeys), les attaquants tournent leur attention vers la « porte de derrière » : la session active. L'hameçonnage d'un [mot de passe](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) 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](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.w3.org/TR/dbsc/). Avec [Chrome 146 (avril 2026) qui intègre DBSC en disponibilité générale sur Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/fr/glossary/cda) 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](https://www.corbado.com/glossary/oauth2) ? 9. Comment DBSC s'intègre-t-il à Shared Signals (CAEP/RISC) pour une réponse aux menaces en temps réel ? ## 2. Comprendre les problèmes fondamentaux et les solutions 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) représente une vulnérabilité ou une limitation critique que DBSC résout. ### 2.1 L'échec de la gestion de session actuelle 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](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), 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. ### 2.2 L'avantage cryptographique de DBSC par rapport aux cookies sécurisés traditionnels DBSC introduit un deuxième facteur d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) 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](https://www.w3.org/TR/dbsc/) « 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. ### 2.3 Synergie entre les clés d'accès et DBSC Les [clés d'accès](https://www.corbado.com/fr/glossary/cda) 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](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) 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](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) 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. | Technologies | Hameçonnage à distance | Bourrage d'identifiants | Vol de jetons | | ------------------------------ | ---------------------- | ----------------------- | ------------- | | **Clés d'accès** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Clés d'accès + DBSC / DPoP** | ✅ | ✅ | ✅ | **Comment les clés d'accès et DBSC fonctionnent ensemble** | **Aspect** | **Clés d'accès** | **DBSC** | **Bénéfice combiné** | | -------------------------- | ---------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------- | | **Portée** | Authentification (connexion) | Gestion de session | Protection de bout en bout | | **Menace atténuée** | Hameçonnage de mot de passe, bourrage d'identifiants | Détournement de session à distance, vol de cookies | Niveau considérablement élevé contre la prise de contrôle de compte | | **Expérience utilisateur** | Connexion sans mot de passe | Protection de session transparente | Expérience fluide et sécurisée | | **Stockage des clés** | Identifiants liés à l'appareil ou synchronisés | Lié à l'appareil (HSM si disponible) | Authentification flexible, liaison de session rigide | | **Déploiement** | Remplace les mots de passe | Améliore les sessions existantes | Améliorations de sécurité progressives | ### 2.4 Leçons tirées de l'échec du Token Binding 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](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) 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)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Il ne dépend pas de la [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) réseau sous-jacente, ce qui le rend compatible avec les équilibreurs de charge, proxys et infrastructures cloud existants. ### 2.5 Implications commerciales et opportunités de ROI 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](https://www.corbado.com/fr/blog/violations-donnees-japon) 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. ## 3. Paysage des menaces : Industrialisation du vol de cookies 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. ### 3.1 La montée en puissance des Infostealers ```mermaid graph TD A[L'utilisateur télécharge
un logiciel malveillant] -->|Exécution| B[L'Infostealer s'active
sur l'appareil] B --> C[Localise les données du navigateur] C --> D[Stockage des cookies
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
identifiants du système d'exploitation] E --> G F --> G G --> H[Crée un fichier journal (log)
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
son propre navigateur] L --> M[Contourne la MFA] M --> N[Prise de contrôle
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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-webauthn-database-guide)) 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](https://www.corbado.com/fr/glossary/malware) 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](https://www.corbado.com/fr/glossary/malware) 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. ### 3.2 Le marché des « Journaux » (Logs) Ces journaux sont agrégés et vendus sur les [places de marché](https://www.corbado.com/passkeys-for-e-commerce) 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](https://www.corbado.com/blog/passkeys-amazon-cognito) 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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) (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](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), apparaissant au serveur comme l'utilisateur revenant sur un onglet actif. ### 3.3 La menace pour Google Workspace & Microsoft Entra 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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) 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](https://www.corbado.com/blog/2sv-vs-2fa) / les clés d'accès bloquent) au vol de cookies (que la [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / les clés d'accès ne bloquent souvent pas). ### 3.4 Les limites de l'« Empreinte numérique de l'appareil » (Device Fingerprinting) 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), 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](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) » qui leur permettent d'usurper parfaitement ces empreintes pour correspondre au profil de la victime, rendant la [détection](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) heuristique inefficace. DBSC remplace ce jeu de devinettes probabiliste par une preuve cryptographique déterministe. ## 4. Architecture technique : Comment fonctionne DBSC [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) introduit une [API et un protocole normalisés](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) 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. ### 4.1 Composants principaux | **Composant** | **Description** | **Rôle dans DBSC** | | ---------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Agent utilisateur (navigateur)** | L'application client (Chrome, Edge, etc.). | Gère la paire de clés, s'occupe de l'interaction avec le HSM et intercepte les requêtes réseau pour y joindre des preuves. | | **Partie utilisatrice (serveur)** | L'application web (par exemple, portail bancaire). | Émet des défis, vérifie les signatures et gère le cycle de vie de la session. | | **Stockage des clés** | Stockage sécurisé (TPM, Secure Enclave ou autre) | Stocke la clé privée. Chrome utilise le TPM sur Windows si disponible ; la spécification est agnostique quant à l'implémentation. | | **Cookie de session** | Un cookie HTTP standard. | Utilisé comme jeton au porteur, mais avec une durée de vie très courte (par exemple, 5 à 10 minutes). | | **Preuve de possession** | Une signature cryptographique. | Un JWT envoyé par le navigateur pour prouver qu'il détient toujours la clé privée. | ### 4.2 Cycle de vie du protocole DBSC 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. ```mermaid 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 ``` #### 4.2.1 Phase 1 : Initiation et Liaison 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](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides), 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 \.\.\ ``` 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 ». #### 4.2.2 Phase 2 : Boucle de cookie de courte duré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. #### 4.2.3 Phase 3 : Actualisation (Preuve de possession) 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: \ Secure-Session-Response: \ ``` 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](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Nuances d'implémentation #### 4.3.1 Défense contre l'attaque « Lift and Shift » ```mermaid graph LR subgraph "Appareil de la victime" A[Session utilisateur
avec DBSC] B[Clé Privée
HSM/TPM] C[Cookie +
ID de Session] A --> B A --> C B -.->|Non exportable| X[Impossible d'extraire
la Clé Privée] end subgraph "Scénario d'attaque" D[RedLine Stealer
infecte l'appareil] D --> E[Vole le Cookie
et l'ID de Session] E --> F[Exporte vers
l'attaquant] end subgraph "Appareil de l'attaquant" G[Importe le cookie
volé] H[Tente d'utiliser
la session] I[Le serveur demande
l'actualisation DBSC] J[Impossible de signer
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. #### 4.3.2 Portée et confidentialité La confidentialité est un objectif de conception central de DBSC. La [spécification W3C](https://www.w3.org/TR/dbsc/) 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. #### 4.3.3 Considérations côté serveur 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. ## 5. Implications commerciales et produit 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é. ### 5.1 Le ROI de la sécurité sans friction Les initiatives de sécurité sont souvent considérées comme des centres de [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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](https://www.corbado.com/fr/blog/violations-donnees-japon) peuvent économiser des millions en pertes dues à la fraude. - **Coûts d'assistance :** La [récupération de compte](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) est onéreuse. [Empêcher le piratage en premier lieu](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) réduit directement cette charge opérationnelle. - **Optimisation de la conversion :** Dans le [commerce électronique](https://www.corbado.com/passkeys-for-e-commerce), 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](https://www.corbado.com/fr/blog/comment-activer-passkeys-android). ### 5.2 Conformité et « État de l'art » Les cadres réglementaires tels que le [RGPD](https://www.corbado.com/fr/glossary/divulgation-selective) 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](https://www.corbado.com/passkeys-for-payment) 2 exige une « [authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) du client » (SCA). Bien que la SCA se concentre sur la connexion, la [liaison dynamique](https://www.corbado.com/fr/blog/liaison-dynamique-passkeys-spc) 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. ### 5.3 Haute assurance vs Assurance modérée Les [livres blancs de l'Alliance FIDO](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) 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](https://www.corbado.com/passkeys-for-banking) 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. ## 6. DBSC vs Alternatives Pour apprécier pleinement DBSC, nous devons le comparer à d'autres technologies qui ont tenté de résoudre des problèmes similaires. ```mermaid 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 ``` ### 6.1 DBSC vs Token Binding 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](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). 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. ### 6.2 DBSC vs DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) 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](https://www.corbado.com/fr/glossary/jwks) signé avec la méthode HTTP, l'URL, l'horodatage et un identifiant unique. Les spécifications de haute assurance comme [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) 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](https://www.corbado.com/fr/glossary/malware)), 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](https://www.corbado.com/fr/blog/application-crud-react-nodejs-express-mysql) est entièrement compromise, un attaquant ne peut pas créer de nouvelles preuves pour des cookies volés sur une autre machine. | Aspect | DPoP | DBSC | | ---------------------- | ------------------------------------------ | ---------------------------------- | | **Cible** | Jetons d'accès + d'actualisation OAuth | Cookies de session de navigateur | | **Stockage des clés** | Contexte de l'application (idéal : API OS) | Adossé au matériel (TPM) | | **Résistance XSS** | ⚠️ Dépendant de l'implémentation | ✅ Clés non exportables | | **Utilisation princ.** | Applications natives, SPA, FAPI 2.0 | Sessions web orientées utilisateur | **Synergie :** Comme le [note l'Alliance FIDO](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), 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](https://www.corbado.com/passkeys-for-banking) 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. ### 6.3 DBSC vs Cookies de courte durée (seuls) 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. ## 7. Shared Signals et Réponse dynamique (CAEP/RISC) ```mermaid %%{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é
(CrowdStrike, Defender) participant IdP as Fournisseur d'Identité
(Okta, Google, Azure) participant SP1 as Fournisseur de Services 1
(Slack) participant SP2 as Fournisseur de Services 2
(Salesforce) participant SP3 as Fournisseur de Services 3
(App Bancaire) participant Session as Session Utilisateur
(Protégée par DBSC) Note over ST,Session: Phase de Détection des Menaces ST->>ST: Détecte un logiciel malveillant sur
l'appareil de l'utilisateur ST->>IdP: Signal RISC :
« Appareil Compromis » Note over IdP,SP3: Phase de Propagation du Signal IdP->>SP1: Événement CAEP :
« Appareil Compromis » IdP->>SP2: Événement CAEP :
« Appareil Compromis » IdP->>SP3: Événement CAEP :
« Appareil Compromis » Note over SP1,Session: Phase d'Application (avec DBSC) Session->>SP1: Prochaine tentative d'actualisation
(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)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), 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](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) 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. ## 8. Prise en charge par les navigateurs et l'écosystème 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. ### 8.1 Google Chrome 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](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://support.google.com/chrome/a/answer/2657289), 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. ### 8.2 Microsoft Edge & Windows Microsoft participe activement. - **État :** Edge a mené un [Origin Trial DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) 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)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) pour l'Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-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. ### 8.3 Apple Safari (WebKit) La position d'Apple est critique pour la couverture mobile. - **État :** WebKit a un [problème de positionnement sur les normes](https://github.com/WebKit/standards-positions/issues/281) é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 ». ### 8.4 Mozilla Firefox Mozilla a un [problème de positionnement sur les normes](https://github.com/mozilla/standards-positions/issues/912) é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. ## 9. Recommandations : Protéger les utilisateurs aujourd'hui 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 : ### 9.1 Actions immédiates (maintenant que Chrome 146 est en GA) 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. ### 9.2 Planification stratégique (les 12 prochains mois) 1. **Adopter une approche hybride** : Utilisez la [détection](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn)), 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](https://www.corbado.com/blog/auth0-passkeys-analysis) 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. ### 9.3 Bonnes pratiques d'implémentation - **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. ## 10. Comment Corbado peut aider : Un pont vers l'avenir 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. ### 10.1 La base : Les clés d'accès Vous ne pouvez pas construire une session à haute assurance sur une connexion à faible assurance. Si un utilisateur se connecte avec un [mot de passe](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) 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. ### 10.2 L'avenir : DBSC pour la détection d'appareils de confiance 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](https://www.corbado.com/fr/blog/cles-acces-liees-appareil-synchronisees), 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](https://www.corbado.com/fr/blog/process-mining-authentification) 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**](https://docs.corbado.com/corbado-connect/features/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](https://www.corbado.com/contact). ### 10.3 Le repli gracieux (la réalité « Hybride ») Pour les prochaines années, le web sera hybride. Certains utilisateurs auront des navigateurs compatibles avec DBSC (Chrome sur [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)) ; d'autres seront sur des systèmes plus anciens. Gérer cette fragmentation est difficile. Le moteur [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/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. ## 11. Conclusion : La voie à suivre pour DBSC 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](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (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](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) et la prise en charge de la Secure Enclave de macOS pré[vue](https://www.corbado.com/blog/vuejs-passkeys) 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](https://www.corbado.com/fr/blog/friction-connexion-tue-conversion) tout en diminuant simultanément les pertes dues à la fraude et les [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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](https://www.corbado.com/features) 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](https://www.w3.org/TR/dbsc/) 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](https://www.corbado.com/fr/blog/comment-passer-totalement-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. ## Foire aux questions (FAQ) ### Comment les DBSC fonctionnent-elles avec CAEP et RISC pour révoquer les sessions compromises en temps réel ? 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. ### Quelle est la différence entre DBSC et DPoP pour la protection des sessions d'applications web ? 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) 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](https://www.corbado.com/fr/blog/application-crud-react-nodejs-express-mysql) elle-même est compromise par un XSS ou un logiciel malveillant. ### Pourquoi DBSC permet-elle des durées de session plus longues sans augmenter le risque de sécurité ? 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. ### Quel retour sur investissement (ROI) les entreprises peuvent-elles attendre du déploiement de DBSC ? 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](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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.