Google Chrome Adds Session Cookie Theft Protection for All Users — DBSC Explained

Google has made a landmark change to how Chrome handles browser authentication that security engineers have been requesting for years. Device Bound Session Credentials (DBSC) — a protocol that cryptographically ties browser sessions to the physical device that created them — is now generally available and rolling out to all Chrome users on Windows, with macOS support following in a subsequent release.

The rollout began on 25 May 2026 for both Rapid Release and Scheduled Release domains, with full availability expected within 60 days. DBSC was first announced in April 2024, entered beta testing for Google Workspace in April 2026, and is now being extended to individual subscribers and personal Google accounts — making it one of the most significant browser security improvements to reach general availability in years.

The target: session cookie theft. This attack class, popularised by infostealer malware families like LummaC2, Raccoon Stealer, and the newly discovered Odyssey Stealer, has become the primary technique for account takeover in 2025–2026 precisely because it bypasses multi-factor authentication entirely. DBSC’s architecture makes stolen session cookies cryptographically unusable on any device other than the one that created them.

1. The Session Cookie Theft Problem

Browser session cookies are one of the foundational mechanisms of the modern web. When you log into a website, the server creates a session and stores a session identifier in a cookie. Every subsequent request includes that cookie, allowing the server to verify that you are still the same authenticated user without requiring you to enter your password with every page load.

The security problem is that these cookies are stored on disk in the browser’s local profile data. On Windows, Chrome stores cookies in a SQLite database at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies. On macOS, they live in ~/Library/Application Support/Google/Chrome/Default/Cookies. These files are readable by the user account — and by any process running with the same user privileges, including malware.

How Infostealers Steal Sessions

Modern infostealer malware — LummaC2, Raccoon Stealer, RedLine, Vidar, and dozens of variants — have built-in modules specifically designed to extract Chrome’s cookie database, decrypt it (Chrome uses the Windows Data Protection API for encryption, which the malware can call as the local user), and exfiltrate the decrypted cookies to attacker-controlled servers.

The entire process — malware execution, cookie extraction, encryption bypassing, exfiltration — typically takes less than 30 seconds. The stolen cookies include session tokens for every website the victim has been authenticated to: email, corporate tools, cloud consoles, banking portals, social media accounts, and any internal applications that use browser-based SSO.

Why MFA Doesn’t Help

The devastating effectiveness of session cookie theft is that it completely bypasses MFA. This surprises many people, but the logic is straightforward: when you log in with your password and MFA code, the server creates a session cookie and gives it to your browser. That session cookie represents a completed authentication — your identity has already been verified, MFA included. When an attacker steals and replays that cookie, they are presenting a credential that proves authentication already occurred. The server has no way to know the cookie is being presented from a different device.

This is why organisations that implemented MFA expecting it to prevent account takeovers have been surprised by the volume of compromises via session cookie theft in 2025 and 2026. MFA prevents password-only attacks. It does not protect sessions that have already been authenticated.

The Scale of the Problem

Infostealer logs — bundles of stolen credentials sold on underground markets — typically contain session cookies for 50–200 websites per infected device. A single successful LLMShare-style campaign targeting an organisation can yield session tokens for corporate email, Google Workspace, Microsoft 365, Slack, GitHub, cloud provider consoles, and ERP systems — all from a single employee device compromise. The attack cost is the price of a Google ad; the potential gain is complete corporate network access.

2. What Is Device Bound Session Credentials?

Device Bound Session Credentials (DBSC) is a new web authentication protocol developed by Google, designed and standardised through the W3C Web Application Security Working Group with contributions from Microsoft. It was first announced publicly in April 2024, entered enterprise beta in April 2026, and reached general availability in May 2026.

DBSC’s fundamental innovation is simple: instead of a session cookie being a standalone token that proves authentication, it becomes a token that only works when presented by the specific device that created it. Stealing the cookie becomes useless — without the device, the cookie cannot be used.

Google describes DBSC as shifting the security paradigm “from reactive detection to proactive prevention.” Traditional defences against session cookie theft involve detecting the theft after it happens (through anomalous login detection, impossible travel alerts, etc.) and responding by revoking sessions. DBSC prevents the stolen credential from being usable in the first place.

3. Technical Architecture: How DBSC Works

DBSC uses hardware-backed cryptography to bind session credentials to a specific device. On Windows, this is the Trusted Platform Module (TPM). On macOS, it is the Secure Enclave. Both are hardware security chips that store cryptographic keys in a way that makes them impossible to extract from the device — even by the operating system or by malware running as the local administrator.

Key Generation and Session Binding

When a DBSC-enabled session is created, the following process occurs:

1. Key pair generation — Chrome requests the device’s TPM/Secure Enclave to generate a new public/private key pair. The private key never leaves the hardware; only the public key is shared.
2. Session registration — Chrome sends the public key to the server alongside the session creation request. The server stores this public key in association with the new session.
3. Proof of possession challenges — Periodically (and particularly when session cookies are being used), the server issues a cryptographic challenge to the browser. Chrome must sign the challenge using the private key stored in the hardware module and return the signature.
4. Session validation — The server verifies the signature using the registered public key. If the signature is valid, the session is authentic. If the private key is not present (because the session cookie is being replayed from a different device), the challenge cannot be answered correctly and the session is invalidated.

What Happens When a Cookie Is Stolen

When an infostealer extracts a DBSC-protected session cookie and exfiltrates it to an attacker’s server:

1. The attacker attempts to use the stolen session cookie from their own machine.
2. The server issues a DBSC proof-of-possession challenge to the attacker’s browser.
3. The attacker’s browser cannot answer the challenge — it does not have the private key, which is locked in the TPM/Secure Enclave of the victim’s device.
4. The server rejects the session. The stolen cookie is cryptographically useless.

Privacy Design

DBSC was specifically designed to avoid creating new tracking vectors. Each DBSC session uses a distinct, newly generated key pair — there is no persistent device identifier that could be used to correlate activity across sessions or websites. The protocol does not transmit any hardware attestation data or device identifiers to the server; it shares only the per-session public key needed to verify possession. This design keeps DBSC from functioning as a device fingerprinting mechanism.

Standards and Interoperability

DBSC was developed through the W3C process and adopted by the Web Application Security Working Group. Google worked with Microsoft on the standard’s design. The W3C standardisation means that other browsers (Firefox, Safari, Edge) can implement DBSC independently, though Chrome is currently the only browser with a production DBSC implementation. For websites that implement DBSC, the protocol is accessible via a new set of HTTP headers and JavaScript APIs that any browser with DBSC support can use.

4. Rollout Timeline and Availability

DBSC’s availability timeline as of June 2026:

The general availability rollout covers: all Google Workspace customers (all tiers), Google One and Individual subscribers, and personal Google accounts. DBSC protection is automatically enabled for sessions on Google properties; no user configuration is required. For non-Google websites to benefit from DBSC, they must implement the server-side DBSC protocol — see the implementation section below.

5. What DBSC Protects Against

DBSC directly addresses the session cookie theft attack class. This is a broad protection because session cookie theft is the root mechanism behind multiple high-profile attack categories:

• Infostealer malware — LummaC2, Raccoon Stealer, Vidar, RedLine, and similar malware that extract browser cookie databases. Stolen cookies become cryptographically unusable on the attacker’s device.
• Evilginx and AiTM phishing — Adversary-in-the-Middle (AiTM) phishing proxies that sit between the user and the real website, intercepting session cookies as they are set. DBSC binds the session to the victim’s device; the cookie cannot be replayed from the attacker’s server.
• Pass-the-cookie attacks — The general attack technique of exfiltrating session cookies from one device and importing them into another browser to authenticate as the victim. DBSC’s device binding makes this attack class unworkable for protected sessions.
• Cross-device session replay — Any scenario where an attacker attempts to authenticate as a user using a stolen session credential from a different device than the one that created the session.

Google reports that on its own properties, where DBSC has been deployed for over a year, there has been a measurable reduction in session theft since deployment began.

6. What DBSC Cannot Stop

Understanding what DBSC does not protect against is as important as understanding what it does. Security professionals who have reviewed DBSC have highlighted several key limitations:

On-Device Session Hijacking

DBSC does not protect against attacks performed from the victim’s own device. If an attacker has Remote Desktop Protocol (RDP) access, a remote access trojan (RAT), or physical access to the victim’s machine, they can use the session from that device — because the device and its TPM are present. The cryptographic proof-of-possession challenge will be answered correctly.

Browser-Level Attacks

Browser extensions with sufficient permissions, browser debug mode exploitation, and memory injection attacks that execute within the Chrome process can access session cookies at a level where DBSC protection does not apply. DBSC binds the cookie to the device and browser process; an attacker who has compromised the browser process itself has access to everything the browser can access.

Non-DBSC-Enabled Websites

DBSC only protects sessions on websites that have implemented the server-side DBSC protocol. Google’s own properties (Gmail, Google Drive, Google Workspace, YouTube, etc.) support DBSC. For other websites — your corporate Slack workspace, your banking portal, your ERP system — DBSC protection only applies if those services have implemented it on their servers. Broad third-party adoption will take time.

Devices Without TPM or Secure Enclave

DBSC requires hardware-backed key storage. On Windows, this requires TPM 2.0. On macOS, the Secure Enclave is present on all Apple Silicon and T2-equipped Intel Macs. Older devices without TPM (pre-Windows 11 era machines without TPM 2.0, or older Intel Macs) cannot use DBSC and will not benefit from the protection. In 2026, most modern enterprise devices include TPM 2.0, but legacy hardware remains a gap.

7. Enterprise and Business Implications

For businesses using Google Workspace — which includes a significant share of Saudi and GCC organisations — DBSC’s general availability represents an immediate, automatic security improvement for employee Google sessions. No configuration is required; the protection is enabled by default for all Workspace accounts.

What Changes for Workspace Admins

• Employee Gmail, Drive, and Google Cloud Console sessions are now bound to specific devices
• Stolen session cookies for Google accounts cannot be replayed from attacker infrastructure
• Session anomaly detection alerts for cross-device session use will be triggered less frequently by legitimate use and more frequently by actual attacks (reducing false positive noise)
• The attack surface of infostealer campaigns targeting Google credentials is meaningfully reduced

What Doesn’t Change

• Non-Google SaaS applications (Slack, Salesforce, Microsoft 365, Zoom, etc.) do not automatically benefit — they need to implement DBSC independently
• The underlying infostealer threat remains; DBSC reduces the damage a successful infostealer infection can cause, but does not prevent the infection itself
• Devices without TPM 2.0 remain unprotected

Recommended Enterprise Actions

• Verify that all Chrome-managed devices in your organisation have TPM 2.0 enabled in BIOS/UEFI settings
• Check device inventory for legacy hardware that predates TPM 2.0 requirements; plan hardware refresh for devices that cannot use DBSC
• Monitor Chrome Enterprise release notes for DBSC policy settings that allow IT admins to control DBSC behaviour for managed devices
• Engage your other SaaS vendors (Slack, Salesforce, Atlassian, etc.) about their DBSC roadmap — website adoption is necessary for DBSC to extend protection beyond Google services

8. Administrator Configuration Guide

Verifying DBSC Status on Chrome

You can verify that DBSC is active on your Chrome installation by navigating to the Chrome DevTools or by checking Chrome’s internal flags:

# Navigate to Chrome's internal DBSC status page
chrome://device-bound-session-credentials/

# Check if TPM is available on Windows
tpm.msc
# Should show "TPM is ready for use" with specification version 2.0

# Check Chrome version (DBSC requires Chrome 126+)
chrome://version/

For Website Developers: Implementing DBSC

If you are a developer and want to implement DBSC protection on your web application, the server-side implementation involves responding to authentication requests with new HTTP headers that initiate the DBSC registration process:

# Session registration response header (sent after successful login)
Sec-Session-Response: session_id="abc123", challenge="", 
                      scope="/app", expiry=3600

# Proof-of-possession endpoint (challenge-response)
# Chrome will POST to this endpoint with a signed challenge
POST /session/dbsc-challenge HTTP/1.1
Content-Type: application/json

{
  "session_id": "abc123",
  "signed_challenge": ""
}

# Server validates signature using stored public key:
# - Valid signature: session accepted, continue normally
# - Invalid/missing signature: session rejected, force re-authentication

Full implementation documentation is available in the Chrome developer documentation and the W3C DBSC specification. The implementation complexity is moderate — it requires changes to your session management system to register public keys and issue periodic challenges, but does not require changes to your authentication mechanism or user database schema.

9. Frequently Asked Questions

Conclusion

Device Bound Session Credentials represents the most significant browser security advancement in years precisely because it targets a specific, concrete attack class — session cookie theft — rather than a vague security improvement. By cryptographically binding sessions to hardware, DBSC makes the entire infostealer-to-account-takeover pipeline measurably less productive for attackers.

The limitations are real: devices without TPM 2.0 are excluded, on-device attacks are not prevented, and third-party website adoption will take time. But for the specific attack pattern that drives the majority of corporate account takeovers in 2025–2026 — infostealer-extracted session cookies replayed from attacker infrastructure — DBSC is genuinely effective.

For Saudi businesses using Google Workspace, DBSC is already protecting your employee Google sessions. No action is required to receive that baseline protection. The next steps are ensuring your fleet has TPM 2.0 enabled, monitoring Chrome Enterprise policies as they mature, and tracking your other SaaS vendors’ DBSC implementation plans.