Google has moved Device Bound Session Credentials (DBSC) into public availability for Windows users on Chrome 146, with macOS support coming in a subsequent release. The feature represents a structural change in how browsers defend against session cookie theft, shifting protection from reactive abuse detection to proactive, hardware-enforced prevention.
Why Cookie Theft Is Hard to Stop
Session cookies are a persistent target for attackers because they frequently carry long-lived authentication tokens. Infostealer malware families have become adept at silently harvesting these cookies from browser storage in memory or on disk, then exfiltrating them to attacker-controlled infrastructure. Once stolen, those tokens can be replayed to access accounts without requiring passwords. Google notes that because sophisticated malware can read local files and memory at the operating system level, no purely software-based control can reliably prevent exfiltration. Stolen sessions are routinely bundled and sold among threat actors.
How DBSC Works
DBSC addresses this by cryptographically binding a session to a specific device. On Windows, it leverages the Trusted Platform Module (TPM); on macOS, the Secure Enclave. At session creation, Chrome generates a public/private key pair inside the hardware module. The private key cannot be exported from the device. When a session cookie is about to expire, Chrome must prove possession of the private key to the server before a new short-lived cookie is issued.
This means any cookie an attacker manages to exfiltrate expires quickly and cannot be refreshed without access to the physical hardware it was bound to. From the web application’s perspective, the integration is designed to be additive: sites add dedicated registration and refresh endpoints to their backends while continuing to use standard cookies on the frontend. Chrome handles key operations and cookie rotation transparently.
Privacy Considerations
The protocol is designed to avoid introducing new tracking surfaces. Each session is backed by a distinct key, preventing correlation of activity across sessions or sites. The protocol does not transmit device identifiers or attestation data beyond the per-session public key needed for proof-of-possession verification, limiting the risk of DBSC being repurposed as a fingerprinting mechanism.
Early Results and Ecosystem Adoption
Google reports a significant reduction in session theft for accounts protected by an earlier version of DBSC that has been running over the past year. The standard has been developed through the W3C Web Application Security Working Group, with input from Microsoft and participation from identity providers including Okta during two Origin Trial phases.
Planned Enhancements
Ongoing development is focused on two areas. First, cross-origin bindings for federated identity scenarios, ensuring a relying party session remains bound to the same device key used during Single Sign-On. Second, advanced registration capabilities that would allow DBSC sessions to be anchored to pre-existing trusted key material, enabling integration with complementary technologies such as mutual TLS certificates and hardware security keys.
Web developers can consult Google’s developer guide and the DBSC specification on GitHub for implementation details and to file bugs or feature requests.