Why Cookie Flags Never Stopped Malware, and What DBSC Actually Does Differently

For roughly two decades, the browser security model for cookies has revolved around a set of well-understood flags. HttpOnly keeps JavaScript from reading a cookie. Secure ensures it only travels over TLS. SameSite constrains cross-site requests. These flags are worth using, and they collectively address a broad surface area of web-based attacks.

None of them help when an infostealer is already running on the machine.

Infostealer malware, a category that includes tools like Redline Stealer, Vidar, and Raccoon, targets the browser’s local cookie database directly. On Windows, Chrome stores cookies in a SQLite file at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies. The cookies in that file are encrypted with DPAPI, the Windows Data Protection API, which derives the encryption key from the user’s login credentials. Any process running as the same user can request that decryption. The malware reads the file, decrypts the values, exports them, and the attacker imports them into their own Chrome profile on a different machine. The session is now theirs. No password was entered. No 2FA prompt was triggered. The browser on the victim’s machine never sent a single anomalous request.

This is the threat model that Google’s Device Bound Session Credentials (DBSC) is designed to address. The mechanism is not a new cookie flag. It is a cryptographic protocol that binds session validity to proof of hardware possession.

Why Token Binding Did Not Work

This is not the first attempt to bind sessions to a device. Token Binding, standardized in RFC 8471 and related RFCs around 2018, attempted to bind HTTP tokens to TLS connections using a device-held key. The browser would generate a key pair, store the private key, and include a signed token in each request. A stolen token was useless without the private key, and the private key never left the device.

Chrome shipped support for Token Binding. It also removed it in 2022, citing lack of adoption. The core problem was that Token Binding required changes at the TLS layer, which meant CDN infrastructure, load balancers, and reverse proxies all had to understand and forward the binding headers across TLS termination points. That coordination cost was high enough that most deployments never happened. A feature that requires every layer of a distributed system to opt in rarely achieves the critical mass needed to justify the implementation burden.

DBSC takes a different approach. It operates at the HTTP application layer, through request and response headers that any server can handle without TLS-layer awareness. The binding is to a device-held key, not to a specific TLS session, which means it survives connection handoffs across CDN edges without special handling.

The Protocol

At the start of an authenticated session, the server signals its intent to use DBSC by returning a Sec-Session-Registration response header:

Sec-Session-Registration: "/session/refresh"; challenge="abc123xyz"; algorithms=ES256

This tells the browser the path for session refresh, provides a challenge for the initial registration, and specifies which signing algorithms are acceptable.

The browser responds by generating an asymmetric key pair. The private key is created as a non-exportable key in a hardware-backed store: the TPM (Trusted Platform Module) on Windows, the Secure Enclave on macOS and iOS, and platform-equivalent mechanisms elsewhere. The browser signs the server’s challenge with this key and sends a Sec-Session-Response header containing a JSON Web Signature (JWS) with the public key embedded:

Sec-Session-Response: eyJhbGciOiJFUzI1NiIsImp3ayI6ey...

The server stores this public key alongside the session. It then issues session cookies with a deliberately short lifetime, on the order of minutes rather than hours or days.

Before those cookies expire, the browser proactively fetches the refresh path. This request includes a Sec-Session-Id header identifying the session and a signed proof-of-possession derived from the device’s private key. The server verifies the signature against the stored public key, and if it matches, issues a fresh set of short-lived cookies.

The loop continues for the duration of the user’s session. From the application’s perspective, cookie-based auth still works the same way. From the security model’s perspective, a cookie that exists without its originating device is now nearly worthless: it expires in minutes, and it cannot be refreshed without a hardware-backed signature that never leaves the original machine.

What Changes for an Attacker

An infostealer can still read the cookie database. DBSC does not prevent the theft itself. What changes is the economic value of that theft. A cookie that expires in five minutes and cannot be refreshed gives an attacker a narrow window that may not be worth the operational complexity of collecting, exfiltrating, and replaying it at scale.

More importantly, DBSC changes the server’s visibility. When the refresh cycle breaks, because a stolen cookie is used on a device that does not hold the private key, the server can detect the absence of a valid refresh and terminate the session. This turns a previously silent, indefinite compromise into a detectable event with a bounded time horizon.

DBSC does not address malware with higher privilege. An attacker with kernel-level access could, in principle, intercept the browser’s signing operations or proxy requests through the victim’s browser in real time. The spec’s threat model explicitly scopes to passive cookie exfiltration, the dominant attack pattern in current infostealer tooling, rather than to active in-browser interception. That is a reasonable trade-off: the attacks it addresses are the ones happening at scale today.

Server Implementation

For a site to support DBSC, it needs three things. First, it needs to issue the Sec-Session-Registration header after authentication, with a generated challenge and a refresh path. Second, it needs a refresh endpoint that validates the JWS proof-of-possession against the registered public key. Third, it needs a fallback path for when a device is lost, replaced, or the DBSC refresh fails for any reason: this typically means falling back to full re-authentication.

The key cryptography on the server side is standard JOSE. Verifying an ES256 JWS is a solved problem in every major language and framework. The harder part is the operational flow around device loss. A user who wipes their laptop and reinstalls Chrome now has a different TPM-backed key, and their existing sessions need to gracefully fall back to re-authentication rather than producing a confusing error.

The spec also requires that per-session keys be generated per-session, not per-device. This is a deliberate privacy decision. If a browser used a single stable device key across all DBSC-enrolled sites, those sites could use the public key as a stable device identifier, enabling cross-site tracking that would be worse than third-party cookies. Per-session keys mean the server only ever sees a key that is meaningful in the context of its own session; two different sites cannot correlate their keys to the same device.

Context in the Browser Security Roadmap

DBSC sits alongside several other in-flight efforts to shrink the cookie theft attack surface. The Private Network Access spec constrains how pages on the public internet can reach local network devices. The Storage Access API renegotiates how cross-site storage works. DBSC is narrower in scope than either: it is specifically about what happens after authentication succeeds and a session begins.

It is also meaningfully different from WebAuthn and Passkeys. Those handle authentication, the moment of credential verification. DBSC handles session continuity, the period after that moment. The two can coexist: a user might authenticate with a Passkey and then have the resulting session protected by DBSC. They solve adjacent problems rather than overlapping ones.

What makes DBSC interesting as a protocol is that it threads a narrow needle. It is hardware-backed enough to defeat passive exfiltration. It is application-layer enough to avoid the infrastructure coordination problems that killed Token Binding. It preserves privacy through per-session key scoping. And it degrades gracefully when hardware backing is unavailable, because a server can choose not to issue Sec-Session-Registration to browsers that do not support it.

The infostealer market has been expanding steadily, and the value proposition of stolen session cookies has grown alongside it. The browser security model was built to defend against web-based attackers; DBSC is a meaningful step toward making it harder for local attackers to profit from the same primitives.