How Device Bound Session Credentials Close the Gap That Cookie Flags Never Could

Cookie theft has been a persistent problem for web security, but not in the abstract way that gets discussed in introductory security courses. The real-world version is specific and ugly: malware running as the current user reads Chrome’s SQLite cookie database from disk, decrypts it using the OS-provided APIs that any user-level process can call, and exports the session tokens. No network interception required. No XSS needed. The attacker imports those cookies into their own browser and lands in an authenticated session, bypassing whatever MFA the user had set up.

This is the attack model that Google’s recent post on Device Bound Session Credentials is aimed at. DBSC is not trying to solve every cookie security problem. It’s trying to make stolen cookie bytes useless by cryptographically tying a session to a device, so that possession of the cookie value is no longer sufficient to authenticate.

Why Existing Protections Don’t Stop This

The cookie security flags that developers reach for (HttpOnly, Secure, SameSite) were designed for different threat models.

HttpOnly blocks JavaScript from reading the cookie. That’s useful against XSS, but it doesn’t stop OS-level process access. Malware doesn’t need to run in the browser’s JavaScript sandbox. It reads the file directly.

Secure ensures the cookie is only sent over HTTPS. Irrelevant once the cookie is already on disk.

SameSite=Strict prevents the cookie from being sent on cross-site requests. Useful for CSRF. Has no bearing on what happens after the cookie has been exfiltrated.

On Windows, Chrome encrypts its cookie store using DPAPI, the Data Protection API. DPAPI ties the encryption key to the current user’s account credentials. The intent is that another user or another machine can’t decrypt the data. But any process running as the same user, including malware, can call CryptUnprotectData() and retrieve the plaintext cookie values. This is not a Chrome-specific weakness; it’s a deliberate design point of DPAPI, and info-stealers exploit it routinely.

Tools like Redline Stealer, Lumma Stealer, and Raccoon Stealer are available as malware-as-a-service and specifically automate this extraction. Several high-profile incidents in recent years involved initial access via stolen session cookies, where attackers bypassed MFA entirely because the session was already authenticated. The cookie was the credential.

What DBSC Actually Does

DBSC adds a second factor to session validity, one that cannot be extracted from disk: a cryptographic private key stored in the device’s TPM (Trusted Platform Module) or equivalent secure hardware, such as the macOS Secure Enclave or the Android Keystore.

The key property is that TPM-backed private keys are not exportable. The TPM will sign data you give it, but the raw key material never appears in memory or on disk. Even if malware has user-level access, there’s nothing to steal.

The protocol has two main phases.

Registration. When a server wants to initiate a DBSC-protected session, it includes a Sec-Session-Registration header in its response. This header specifies a challenge, a registration endpoint URL, and the key type the server expects (typically ES256, an ECDSA key using P-256). The browser generates a key pair via the platform’s secure hardware, then sends the public key and a signed registration proof to the server’s registration endpoint. The server stores the association between the session and the public key.

Refresh. Sessions don’t live forever. At configurable intervals, the server sends a Sec-Session-Challenge header containing a fresh nonce. The browser’s DBSC machinery picks this up and sends a signed response to the server’s refresh endpoint, proving it still controls the private key. The server verifies the signature against the stored public key and, if valid, refreshes the session cookie. If the signature is missing or invalid, the server can force re-authentication.

The signed proof is a JWT-like structure binding the session ID, the server’s nonce, a timestamp, and the origin, all signed by the TPM-backed key. An attacker who steals the cookie bytes cannot produce this proof, because they don’t have the private key and the TPM won’t sign for them.

How This Compares to WebAuthn

WebAuthn also uses device-bound asymmetric keys and is often described as the solution to password and phishing problems. The distinction is worth making explicit.

WebAuthn secures the authentication step: proving your identity to log in. Once you’ve authenticated with WebAuthn and received a session cookie, that cookie is a conventional bearer token again. If someone steals it at that point, WebAuthn doesn’t help.

DBSC operates at the session layer, after login. It continuously requires proof of device possession throughout the session’s lifetime, not just at the moment of authentication. The two mechanisms are complementary. WebAuthn for the front door, DBSC for the duration of the session once you’re inside.

What Servers Need to Do

DBSC requires server-side participation. The browser handles the cryptographic operations, but servers need to implement several things:

1. A registration endpoint that receives and stores public keys associated with sessions.
2. Logic to emit Sec-Session-Registration headers when starting new sessions.
3. Logic to emit Sec-Session-Challenge headers to trigger refresh proofs on session-sensitive routes.
4. Signature verification against stored public keys at the refresh endpoint.
5. A fallback path for clients that don’t support DBSC, since the mechanism is additive.

The fallback behavior is important for rollout. DBSC-capable browsers use it; browsers without support fall through to standard cookie behavior. This means servers can enable DBSC without breaking the experience for users on unsupported clients.

The WICG specification for DBSC has been developed in the open, and the explainer on GitHub covers the full protocol design. The server-side implementation is not trivial, but the verification step is standard JWT/JWS verification against an ECDSA public key, which has good library support in every major language.

What It Doesn’t Fix

DBSC closes a specific gap. It does not close everything.

Privileged malware remains a problem. If an attacker has kernel-level access or is running as SYSTEM, they may be able to interact with the TPM directly, intercept signing operations, or bypass the TPM abstraction layer entirely. The threat model DBSC targets is user-level info-stealers, which is the prevalent class of attack today. It is not designed to defend against kernel rootkits.

The refresh interval creates a window. DBSC validates device possession at refresh time, not on every individual request. Within a refresh interval, a stolen cookie is still technically valid. Servers can tune refresh intervals to shrink this window, but there’s a latency and server-load tradeoff.

Key lifecycle is messy in practice. If a user reinstalls their OS, migrates to a new device, or has their browser profile sync in a way that doesn’t carry the TPM-bound key, their session breaks. Servers need to handle graceful fallback to re-authentication in these cases. Chrome’s browser profile sync intentionally does not sync TPM-backed keys, which is correct behavior but means cross-device sessions won’t be DBSC-protected.

DBSC also does nothing for server-side vulnerabilities. Authorization logic flaws, SQL injection in session lookups, insecure direct object references: none of that is in scope here.

Where This Stands

Chrome has been running origin trials for DBSC, with Google’s own services among the early adopters. The feature is documented as an active WICG incubation, which is the standard path before it moves to a standards body. Other browser vendors are watching, but as of now Chrome is where the implementation work is happening.

For teams building high-value web applications, especially anything handling financial data, account credentials, or sensitive communications, DBSC is worth tracking closely. It addresses a class of attack that has been genuinely difficult to mitigate without hardware involvement. The reliance on TPMs means the protection degrades gracefully to zero for devices that lack them, rather than creating a false sense of security.

The broader point is that DBSC is part of a shift toward treating device identity as a first-class session property, not just a login-time check. That’s the right direction for an environment where info-stealers are commodity tools and session hijacking bypasses MFA routinely. Whether the deployment story catches up to the threat model fast enough is a separate question, and one that depends on how quickly server-side adoption follows the browser implementation.