For years, web security teams have struggled to close one of the most stubborn gaps in online authentication. Attackers continue to use stolen session cookies to bypass passwords, multi‑factor checks, and every other gate defenders put in their way. Once a valid cookie is stolen, the thief gains the same privileges as the real user. It is an old problem that keeps repeating because the web’s basic session model has not changed.
The industry has spent years trying to raise the bar. Security attributes such as Secure, HttpOnly and SameSite limited how cookies could be sent or read, reducing exposure but never replacing the core idea that a cookie is enough to prove identity. Later, research projects like Token Binding and Channel ID aimed to attach cookies to encryption keys within the browser’s connection, making them harder to reuse somewhere else. These efforts introduced strong concepts but proved too difficult to adopt across browsers, servers and identity systems that all evolved at different speeds.
That persistent gap became the foundation for infostealer malware. Once a device is infected, the malware extracts browser cookies from memory or disk and uploads them to a remote server. Each stolen cookie represents a live, authenticated session that attackers can reuse or sell. In Lunar’s exposure data, we frequently see this activity reflected in the marketplace trade of “ready‑made sessions” that allow instant account takeover.
Google’s new Device Bound Session Credentials, or DBSC, enters at exactly this point. It is designed to make stolen cookies useless outside the device where they originated.
How DBSC Works
DBSC was publicly released for Windows users in Chrome 146 on April 9, 2026. When a browser registers a session, it generates a public‑private key pair and stores the private key inside the computer’s secure hardware, such as the Trusted Platform Module on Windows or the Secure Enclave on macOS. The web server keeps the public key tied to the session and later asks Chrome to prove that the private key still exists when refreshing cookies. To the user, the login process appears unchanged, but underneath it, the browser must now show that it still has the correct key before the session can continue.
If a cookie is stolen and used on another system, it fails this proof step. The attacker might have the cookie, but not the device key. In Google’s internal rollout, this architecture already produced a steep drop in successful session hijacking, demonstrating that the shift from possession of a token to possession of a device can change outcomes quickly.
Why Previous Defenses Fell Short
Earlier improvements to cookie security focused on controlling traffic rather than redefining trust. They made it harder for cookies to appear in the wrong places but did not prevent someone from copying them outright. Token Binding and Channel ID went further by trying to link authentication artifacts to the encryption layer itself, but browser support and deployment complexity limited adoption.
DBSC offers the same security principle in a simpler form. Everything happens at the browser layer using ordinary web protocols, and Chrome handles the cryptography, rotation and storage automatically. Developers can continue using familiar login flows while gaining stronger protection against replayed sessions.
A Step Toward Possession‑Based Authentication
The emergence of DBSC fits into a broader movement toward authentication based on proof of possession. OAuth’s DPoP standard (Demonstration of Proof of Possession) already applies the concept to API tokens. Both approaches rely on showing ownership of a private key when presenting a credential. DBSC extends this idea to browser sessions, giving end users the same assurance that corporate APIs are beginning to use.
Each DBSC session uses its own key, which limits the ability to track users across sessions and keeps privacy intact. The project has moved through W3C’s standards process with input from Microsoft, Okta and others, suggesting that this design will become a shared element of the web ecosystem rather than a single‑vendor feature.
Looking Ahead
Google plans to expand DBSC to federated identity, so that sessions created by identity providers can remain bound to the same device key. Future versions may also include support for hardware tokens or software‑based keys for devices without secure hardware. These steps point to a future where web sessions are always verified, not just validated once at login.
For defenders, this represents meaningful progress. Cookie theft will no longer guarantee account access, and attackers relying on infostealer exports will need new strategies as sessions lose their portability.
At Lunar, we view DBSC as more than another browser feature. Infostealers turned session hijacking into a commodity market, and DBSC begins to take that advantage away. It shows what happens when the web stops adding layers of defense and instead redefines the underlying mechanics of trust. That kind of change lasts.
Previous post