DEV Community: Suliman Abdulrazzaq

What DBSC Does and Doesn't Protect You From

Suliman Abdulrazzaq — Fri, 12 Jun 2026 12:30:04 +0000

Most writing about DBSC is either a spec or a pitch. This is neither. DBSC is a genuinely good defense against the most common session attack on the internet, and it has a precise boundary that the marketing language tends to blur. If you're deciding whether to adopt it — or trying to explain to a security review what it does and doesn't buy you — the boundary is the whole conversation.

Short version: DBSC kills remote cookie theft and replay. It does not turn a session into a hardware token for every threat, and exactly how much it protects depends on which tier the user lands in.

The attack it's built for

A session cookie is a bearer token: hold it, be the user. The dominant way that goes wrong at scale is steal the cookie, replay it from somewhere else. Infostealer malware lifts cookies out of the browser profile and ships them off. XSS exfiltrates them. A malicious extension reads them. A misconfigured proxy logs them. In every case the attacker ends up with the cookie value on their machine and uses it to ride your session — no password, no MFA prompt, because the cookie already cleared both.

DBSC binds the session to a private key that lives on the user's device and never travels. When the attacker replays the cookie from their machine, the next refresh demands a signature their machine can't produce. The session dies. That's the core win, and it's a big one: it neutralizes the single most common takeover path.

The tiers protect different amounts

This is the part that matters most and gets glossed over. DBSC binding comes in two strengths.

Threat	`dbsc` (native, TPM/Secure Enclave)	`bound` (Web Crypto polyfill, IndexedDB)
Remote cookie theft + replay	Stopped	Stopped
MFA bypass via stolen cookie	Stopped	Stopped
Infostealer reading the browser profile on disk	Stopped (key is in hardware)	Not stopped (encrypted blob on disk is recoverable)
Malware running inside the browser process	Not stopped	Not stopped

The native tier (dbsc) puts the private key inside a TPM or Secure Enclave. No software on the machine — including malware running as the user — can read it. That's the strong form, and it's Chromium-on-supported-hardware only today.

The bound tier is a polyfill for everyone else (Firefox, Safari, older Chromium). It uses a non-extractable Web Crypto key in IndexedDB. The JavaScript API genuinely can't export that key — so XSS can't steal it, which is why remote theft is still defeated. But the encrypted key blob does sit in the browser profile directory on disk. Infostealer malware running with the victim's privileges can read that directory and, depending on the OS keystore, decrypt it. So the polyfill defends against remote theft but not against on-device malware with disk access.

If you treat bound as if it were dbsc, you've overstated your protection to the one audience (security reviewers) who will check. Be precise: bound defeats remote cookie theft; only dbsc additionally defeats local infostealers.

What it does not protect, at any tier

Malware inside the browser process. If the attacker is executing in the page or the browser itself, they have the live, authenticated session the same way the user does. They don't need to steal a cookie; they are the session. DBSC binds the cookie to the device — and the malware is on the device, in the browser. No cookie-binding scheme fixes this; it's a different problem (endpoint security).

Non-cookie and non-JWT credentials. DBSC binds session cookies. It says nothing about Primary Refresh Tokens (PRTs), Kerberos tickets, OAuth refresh tokens stored outside the cookie jar, or API keys in a config file. If your real session-bearing secret isn't the cookie DBSC bound, DBSC isn't protecting it. This catches people in enterprise SSO setups where the cookie is only one link in the chain.

Devices without the hardware. No TPM, no Secure Enclave, no native tier — the user falls back to the polyfill (weaker, as above) or to nothing. You don't get hardware binding on hardware that can't do it.

Authentication itself. A session exists before DBSC binds it. DBSC protects an already-authenticated session; it is not a login mechanism and not a replacement for MFA. It makes a stolen post-login cookie useless — it does nothing about phishing the login itself.

The window between refreshes

Session-level binding (registration + refresh) re-checks the key on a cycle — say every ten minutes. Between two checks, a cookie stolen just now is still valid, because the next signature check hasn't happened yet. That's a real, if small, window.

Closing it requires the optional per-request proof: a signature on individual sensitive requests, not just on refresh. With that in place on a guarded route, a stolen cookie fails on the first such request rather than surviving until the next refresh. It's opt-in per route because it has a cost (the client signs each guarded call), and many apps accept the refresh-cycle window for everything except payments and credential changes. The point is to know the window exists and decide deliberately, route by route, rather than assume binding is instantaneous everywhere.

How to think about adopting it

DBSC isn't a silver bullet and it isn't snake oil. It's a sharp tool with a clean edge:

It eliminates the most common real-world takeover (remote cookie replay) for essentially all modern browsers.
It gives you a stronger guarantee on Chromium-with-TPM (defeats local infostealers too) and an honest, weaker-but-still-useful one everywhere else.
It does not absolve you of endpoint security, MFA, protecting non-cookie credentials, or guarding the login itself.

The right mental model is defense in depth, not replacement. DBSC closes the cookie-replay door — the door attackers walk through most often — while leaving the others exactly where they were. That's worth a lot, precisely because it's a specific, verifiable claim and not a vague "more secure."

If you want the mechanics behind these guarantees, I wrote up how the protocol actually works and the full server-side threat model is public. The honest boundary is the selling point: you can hand it to a security team and every line holds up.

Implementing DBSC Server-Side: A Language-Agnostic Guide

Suliman Abdulrazzaq — Fri, 12 Jun 2026 12:27:14 +0000

If you're building a DBSC server outside Node — Go, Python, Rust, Java, PHP — you don't need a library, you need the wire contract: which endpoints to expose, the exact bytes in each header, how to verify the proofs, and the order of the checks. This is that contract, framework-free, with short pseudo-code instead of any one language's idioms. The companion Express tutorial shows it concretely in Node; this is the version you port.

Everything below is drawn from a language-neutral spec with test vectors — concrete inputs and expected outputs your implementation can self-check against without driving a real browser.

The surface area

You implement two HTTP endpoints and one response header. That's the whole native protocol.

POST /dbsc/registration — the browser sends its newly generated public key here.
POST /dbsc/refresh — the browser re-proves possession of the key here, on a cycle.
A Secure-Session-Registration response header you attach to your login response.

Plus a small amount of state: a session record and a short-lived challenge store.

The headers, exactly

Case-insensitive on inbound. Some Chromium builds straddle a rename, so accept the legacy names and emit both.

Direction	Header	Carries
Server → Browser	`Secure-Session-Registration`	"start a session" instruction, after login
Server → Browser	`Secure-Session-Challenge`	a fresh challenge JTI, in the 403 that starts a refresh
Browser → Server	`Secure-Session-Response`	the JWS proof, on registration and refresh
Browser → Server	`Sec-Secure-Session-Id`	the session id on refresh (the cookie is gone by then)

Legacy inbound names you MUST also accept: Sec-Session-Response, Sec-Session-Registration. Legacy outbound names you SHOULD also emit: Sec-Session-Registration, Sec-Session-Challenge.

The registration header value is a strict little grammar:

(<alg>);path="<registrationPath>";challenge="<jti>";id="<boundCookieName>"

Joined by ; with no spaces, values double-quoted, algorithm in parentheses (ES256 or RS256). path is where the browser POSTs its key — not the refresh URL. id is the bound cookie's name; Chromium requires it.

The proofs

Both registration and refresh send a compact JWS: <protected>.<payload>.<signature>, each segment base64url.

Registration JWS — carries the public key:

header:    { "alg": "ES256", "typ": "dbsc+jwt", "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } }
payload:   { "jti": "<challenge>" }
signature: ECDSA P-256 over <protected>.<payload>, by the private key matching the jwk

Refresh JWS — identical, but with no jwk (you already stored the key). A refresh JWS that includes a jwk is a protocol error and must be rejected.

The registration JWS is self-signed: the key is in the header, the signature is by that key. Verifying it proves possession without the private key ever leaving the device.

Verifying a JWS (the part to get exactly right)

This is where an implementation either holds or quietly leaks. Pseudo-code:

function verify_dbsc_jws(compact_jws, expected_jwk_or_none):
    header, payload, signature = split_on_dot(compact_jws)
    h = base64url_decode_json(header)

    # 1. Algorithm allowlist — reject everything else BEFORE loading a key.
    if h.alg not in {"ES256", "RS256"}:
        fail "ALG_NOT_ALLOWED"          # this rejects "none" and HS256 confusion

    # 2. Pick the key.
    if expected_jwk_or_none is None:    # registration: key is in the header
        jwk = h.jwk
    else:                               # refresh: use the stored key, ignore any header jwk
        jwk = expected_jwk_or_none

    # 3. Verify signature over the raw "<protected>.<payload>" bytes.
    signing_input = header_b64 + "." + payload_b64
    if not crypto_verify(jwk, h.alg, signing_input, base64url_decode(signature)):
        fail "SIGNATURE_INVALID"

    return base64url_decode_json(payload)   # contains jti

The algorithm allowlist in step 1 is not optional. If you skip it, an attacker can send alg: "none" (no signature) or alg: "HS256" and try to make you HMAC with the public key as the secret. Reject anything that isn't ES256/RS256 before you touch a key.

State you keep

Two stores, abstracted:

Session:   { id, tier, lastRefreshAt, ... }       # tier in {none, dbsc, bound}
BoundKey:  { sessionId, kind, jwk, algorithm }     # kind in {native, bound}
Challenge: { jti, sessionId, consumed, expiresAt } # single-use, short-lived

A session can hold two bound keys (one native, one bound) — that's how Chromium does both hardware-backed refresh and software per-request proofs. Key them by kind.

The one hard requirement on the challenge store: consume must be atomic. The JTI is single-use, and a non-atomic check-then-delete opens a replay window. Use a single atomic operation — a Lua script on Redis, UPDATE ... WHERE consumed = false on SQL — that both checks and flips in one step and tells you whether you were the one who consumed it.

Registration handler, in order

on POST /dbsc/registration:
    jws = header("Secure-Session-Response") or fail "MISSING_RESPONSE_HEADER"
    payload = verify_dbsc_jws(jws, expected_jwk=None)   # self-signed
    jwk, alg, jti = payload.jwk, payload.alg, payload.jti

    ch = challenges.get(jti)
    assert ch exists          else "CHALLENGE_NOT_FOUND"
    assert not ch.consumed    else "CHALLENGE_CONSUMED"
    assert not ch.expired     else "CHALLENGE_EXPIRED"
    assert ch.sessionId == this_session else "JTI_MISMATCH"
    assert no existing native key for session else "SESSION_ALREADY_REGISTERED"

    if not challenges.consume_atomic(jti):   # the race guard
        fail "CHALLENGE_CONSUMED"

    store BoundKey{ sessionId, kind: "native", jwk, algorithm: alg }
    session.tier = "dbsc"; session.lastRefreshAt = now()

    respond 200, json_session_config(), set bound cookie

Refresh handler, in order

The session id comes from the Sec-Secure-Session-Id header — the cookie is gone.

on POST /dbsc/refresh:
    sessionId = header("Sec-Secure-Session-Id")

    if no "Secure-Session-Response" header:        # first leg — no proof yet
        jti = new_challenge(sessionId)
        respond 403, header "Secure-Session-Challenge"=jti, set challenge cookie
        return                                      # MUST be 403, never 401

    key = bound_key(sessionId, kind="native") or fail "KEY_NOT_FOUND_NATIVE"
    payload = verify_dbsc_jws(jws, expected_jwk=key.jwk)   # stored key
    validate challenge(payload.jti)                        # exists/unconsumed/unexpired/belongs

    if verification failed:
        challenges.consume_atomic(payload.jti)
        session.tier = "none"          # demotion is what kills the replayed cookie
        fail "SIGNATURE_INVALID"

    challenges.consume_atomic(payload.jti)
    session.lastRefreshAt = now()      # tier stays "dbsc"
    respond 200, json_session_config(), set fresh bound cookie

The JSON session config

Both successful handlers return this (200, Content-Type: application/json):

{
  "session_identifier": "<sessionId>",
  "refresh_url": "/dbsc/refresh",
  "scope": { "include_site": true, "scope_specification": [] },
  "credentials": [
    { "type": "cookie", "name": "<boundCookieName>",
      "attributes": "Path=/; Secure; HttpOnly; SameSite=Lax" }
  ]
}

Two rules that fail silently if you break them:

It must be 200 with this body. A 204, or a 200 with no body, makes Chromium treat the session as opted-out and abandon it. No error is raised.
credentials[0].attributes must match your real Set-Cookie byte-for-byte. Any drift — a different SameSite, an extra space — and the browser drops the binding. Generate the cookie and this string from the same source so they can't diverge.

Status codes that actually matter

Status	When	Browser does
`403` + `Secure-Session-Challenge`	refresh needs proof	signs and retries
`401`	—	ignores it; session dies. Never use 401 here.
`200` + JSON config	registration/refresh ok	updates session, replays request
`200` without JSON (e.g. `204`)	—	treats as opt-out; session dies

Things that aren't in the protocol but you still need

HTTPS, with __Host- cookies. Chrome drops them over plain HTTP. Non-negotiable in production.
Rate-limit the two endpoints. They're unauthenticated by nature (the proof is the auth). The algorithm is your call; the requirement is that you have one.
Behind a TLS-terminating proxy, derive https from the forwarded protocol if you put an explicit scope.origin in the config. Get the scheme wrong and Chromium drops the session.

Self-checking without a browser

The hardest part of building this is that almost every mistake fails silently — the session just doesn't bind, with no error to chase. That's why the spec ships test vectors: real registration headers, JWS proofs, and per-request proofs with known inputs and expected outputs. Run your implementation against those before you ever point a browser at it. If your verifier accepts the sample registration JWS and produces the sample header byte-for-byte, you've eliminated the whole class of silent wire-format bugs in one pass.

The protocol is genuinely small — two endpoints and a header. The discipline is in the details: the atomic consume, the 403-not-401, the byte-exact cookie, the algorithm allowlist. Get those four right and the rest follows.

Implementing Device Bound Session Credentials (DBSC) on Express

Suliman Abdulrazzaq — Fri, 12 Jun 2026 12:25:33 +0000

A stolen session cookie is a full account takeover. The attacker copies the cookie out of the browser profile — infostealer malware does exactly this, at scale — pastes it into their own browser, and they are you. Every defense we've layered on (SameSite, Secure, HttpOnly, short TTLs) reduces the blast radius but doesn't close the hole: a bearer token is a bearer token, and whoever holds it wins.

Device Bound Session Credentials (DBSC) closes it. Chrome shipped it to stable in 146. The idea is small and the consequences are large: at login the browser generates an EC P-256 keypair inside the device's hardware key store — TPM 2.0 on Windows, Secure Enclave on Apple Silicon — and hands your server only the public key. The private key never leaves the hardware and can't be exported, not even by malware running as the user. Your server binds the session to that key. Every few minutes the browser proves it still holds the key by signing a server challenge. Copy the cookie to another machine and the next refresh fails, because that machine can't produce the signature. The session dies within one refresh cycle.

This post is the server side, on Express, end to end. I'll use dbsc-toolkit — the library I wrote and verified against Chrome 147 on real TPM 2.0 hardware — so the protocol plumbing is handled and we can focus on what you actually wire.

What you're building

Three moving parts on the server:

Two protocol routes — /dbsc/registration (the browser POSTs its public key here) and /dbsc/refresh (the browser re-proves possession here). You don't write these; the middleware mounts them.
A bind call in your login route — after you've authenticated the user the usual way, you start the binding.
An optional guard on sensitive routes that demands a fresh proof from the bound device.

Your existing auth doesn't change. DBSC rides alongside it.

Install

npm install dbsc-toolkit express

Framework and storage drivers are optional peer deps, so you only pull what you use. Memory storage is fine to start; swap in Redis or Postgres for anything that has to survive a restart.

The minimum working server

import express from "express";
import { randomUUID } from "node:crypto";
import { createDbsc } from "dbsc-toolkit/express";
import { MemoryStorage } from "dbsc-toolkit/storage/memory";

const app = express();
app.use(express.json());

// Configure once. install() mounts the protocol routes, the bound-route
// JSON parser, the browser SDK, and `trust proxy` — all in one call.
const dbsc = createDbsc({ storage: new MemoryStorage() });
dbsc.install(app);

app.post("/login", async (req, res) => {
  // ... your real authentication: verify password, look up the user ...
  await dbsc.bind(res, randomUUID(), { userId: req.body.username });
  res.json({ ok: true });
});

app.get("/me", (_req, res) => {
  const { sessionId, tier } = res.locals.dbsc;
  if (!sessionId) return res.status(401).json({ error: "not authenticated" });
  res.json({ sessionId, tier });
});

app.listen(3000);

That's the whole server. dbsc.bind() is doing five things under the hood: it writes the session row, issues a single-use challenge, builds the Secure-Session-Registration response header, sets both the legacy and current header names for compatibility, and sets the short-lived cookies Chrome needs to complete registration. You call one function in the one place you already have — the login route.

HTTPS is not optional

DBSC uses __Host- prefixed cookies, which Chrome will only accept over HTTPS with the Secure flag and no Domain attribute. On plain http://localhost Chrome silently drops them and nothing binds. For local development either run a TLS proxy in front of your server (local-ssl-proxy --source 3001 --target 3000) or push to any host that terminates HTTPS at the edge. If you set secure: false for HTTP-only local testing, native DBSC still won't engage — Chromium refuses the protocol over HTTP — but the polyfill path (more on that below) works over Web Crypto, which is enough to exercise the flow.

Watching it work

Open the app in a Chromium 146+ browser over HTTPS, open DevTools → Network, and hit POST /login. Within a second or so you'll see a request you never wrote: POST /dbsc/registration, initiated by the browser itself. That request carries a JWS signed by the freshly minted hardware key. The server verifies the self-signature, stores the public key under the session ID, sets the __Host-dbsc-session cookie, and returns a JSON session config that tells the browser how and when to refresh.

Hit GET /me afterward and you'll see tier: "dbsc". That's the proof the session is hardware-bound.

The tier model, and the browsers that aren't Chrome

Native DBSC is Chromium-only today. Firefox and Safari don't speak it yet. If you stopped at native, you'd be protecting maybe a third of your users and leaving everyone else on plain bearer cookies — which is an awkward thing to put in a security review.

So dbsc-toolkit also ships a Web Crypto polyfill. It does the same session binding with a non-extractable CryptoKey held in IndexedDB. It's a notch weaker than a TPM — the key lives in the browser's storage rather than a separate security chip, so it doesn't defend against malware with full access to the user's own machine — but it defeats every remote cookie-replay scenario, which is the threat that matters for theft-at-scale. That gives you three states, exposed as res.locals.dbsc.tier:

dbsc — native, hardware-backed key (Chromium + TPM/Secure Enclave).
bound — polyfill key in IndexedDB (Firefox, Safari, older Chromium).
none — unbound or stale.

One server, every modern browser, no per-browser branching in your code. If you specifically want native-only and no polyfill, there's a bound: false switch — but the default covers everyone.

Guarding the routes that matter

Binding the session is half the value. The other half is requiring a fresh, per-request proof before you do something sensitive — a payment, a password change, exporting data. That's one guard:

import { requireProof } from "dbsc-toolkit/express";

app.post("/payment", requireProof(), (req, res) => {
  res.json({ ok: true, tier: res.locals.dbsc.tier });
});

requireProof() rejects any request that isn't coming from the bound device — a replayed cookie from elsewhere never gets here. It works the same across all three tiers, so you write the guard once and it does the right thing whether the user is on a TPM or the polyfill.

The one gotcha that bites client code

There's a timing detail worth knowing before it confuses you. Binding completes after the login response returns. On Chromium the browser POSTs /dbsc/registration a few hundred milliseconds later; on Firefox/Safari the polyfill first probes for native support for a few seconds and then registers. Either way, if your frontend checks the session the instant login resolves, it sees tier: "none" even on a fully supported browser — not because anything failed, but because binding hasn't happened yet.

Don't poll to wait it out; the delay is variable and you'd be guessing. The browser SDK gives you a promise that resolves exactly when binding finishes:

const outcome = await initBoundDbsc();
if (outcome.phase !== "unbound" && outcome.phase !== "error") {
  // bound — now it's safe to call your guarded routes
}

Why I wouldn't hand-roll the server side

The flow above looks simple from the application's seat, and that's the point — the library is absorbing a set of wire-format rules that are individually small and collectively brutal to discover. A few I burned real time on, all of which the W3C draft does not make obvious:

The refresh endpoint must answer 403 on a missing or invalid proof — never 401. Chromium silently ignores a 401 and lets the session die instead of restarting the challenge. The first time I returned the "correct" 401, the session just quietly stopped refreshing and I had no error to chase.
Registration and refresh must respond 200 with the JSON session-config body, not a bare 204. A 204 looks perfectly fine in DevTools and makes Chromium terminate the session anyway.
The credentials[].attributes string in that JSON has to match the real Set-Cookie header byte-for-byte. Any drift and the browser drops the binding.
Challenge consumption has to be atomic. The JTI is single-use; a non-atomic check-then-delete opens a replay window.

None of these throw an exception. They fail by the session quietly not binding, which is the worst kind of bug to debug against a browser. That's the work the library exists to have already done — it's verified end-to-end against Chrome 147 on real TPM hardware, and the exact wire contract is written up as a language-neutral spec with round-trip test vectors if you do want to implement it yourself in another language.

Where to go next

The runnable demo with both cookie-session and JWT login modes: examples/express.
Adapters for Fastify, Hono, and Next.js App Router ship in the same package.
The protocol spec and test vectors, if you're implementing DBSC anywhere outside Node: spec/.

DBSC is the first session-security primitive in a long time that actually moves the bearer-token problem instead of just shrinking it. Chrome shipping it to stable means it's no longer a research toy — it's something you can turn on for real users this quarter. The server side is genuinely a few lines; the hard part was the wire details, and those are written down now.

DBSC Explained: How Device Bound Session Credentials Actually Work

Suliman Abdulrazzaq — Fri, 12 Jun 2026 12:17:55 +0000

A session cookie is a bearer token. Whoever holds it is the user — the server has no way to tell the real browser apart from a copy of the cookie pasted into a different one. That single property is behind a huge share of real-world account takeovers: infostealer malware lifts cookies out of the browser profile, ships them to an attacker, and the attacker is logged in as you without ever touching your password or your MFA.

Device Bound Session Credentials (DBSC) is the W3C protocol that removes the "whoever holds it" part. Chrome shipped it to stable in version 146. This post walks the entire protocol end to end with no framework and no specific language — just what travels on the wire and why each piece is shaped the way it is. If you've read the W3C draft and wanted the version that explains the reasoning, this is that.

The core idea in one paragraph

At login, the browser generates a public/private keypair inside the device's hardware key store — a TPM 2.0 on Windows, the Secure Enclave on Apple Silicon Macs. It sends the server only the public key. The private key never leaves the hardware and cannot be exported, not even by code running as the user. The server ties the session to that public key. From then on, the browser proves it still holds the matching private key by signing server-issued challenges. A cookie copied to another machine can't produce those signatures — that machine doesn't have the key — so the copied session dies on its next refresh.

The cookie still travels normally. DBSC doesn't encrypt it or hide it. It makes the cookie insufficient on its own: possession stops being proof of identity.

Two flows, one session

There are exactly two server endpoints and three things the server does: it tells the browser to make a key (registration), it re-checks the key periodically (refresh), and it exposes a session tier so the application can refuse requests that aren't backed by a live binding.

Crucially, the server is reactive. It doesn't initiate anything. It sets one response header after login and then answers two endpoints when the browser comes knocking. The browser decides when to register and when to refresh.

Registration: binding the session

Registration happens right after your normal login succeeds. The login response carries an extra header:

Secure-Session-Registration: (ES256);path="/dbsc/registration";challenge="<jti>";id="__Host-dbsc-session"

That value is a small grammar, joined by semicolons with no spaces: the algorithm in parentheses, the path where the browser should POST its key, a one-time challenge (a JTI — a unique nonce), and the id naming the cookie the bound session will use.

The browser sees that header, generates its hardware keypair, and — on its own, within about a second — POSTs to the path:

sequenceDiagram
    participant TPM as Hardware key store
    participant Browser
    participant Server
    Note over Browser,Server: user logs in normally
    Server-->>Browser: 200 + Secure-Session-Registration header
    Browser->>TPM: generate EC P-256 keypair
    TPM-->>Browser: public key (private stays inside)
    Browser->>Server: POST /dbsc/registration<br/>Secure-Session-Response: <JWS>
    Server->>Server: verify self-signature, store public key
    Server-->>Browser: 200 + JSON session config + bound cookie

The proof the browser sends is a JWS (JSON Web Signature) with a specific shape:

Protected header: { "alg": "ES256", "typ": "dbsc+jwt", "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } }
Payload:          { "jti": "<the challenge from the header>" }
Signature:        ECDSA P-256 over header.payload, made with the private key

The clever part: this JWS is self-signed. The public key is embedded in the header, and the signature is made by the matching private key. So the server can verify the signature using only what's in the message — and that verification proves the sender holds the private key without the private key ever being transmitted. The server stores the public key against the session, marks the session as bound (tier: dbsc), and responds 200 with a JSON config telling the browser where and how often to refresh.

A detail that trips up everyone who implements this by hand: that response must be 200 with the JSON body. A bare 204 No Content looks correct in DevTools and causes Chromium to treat the whole thing as an opt-out and silently abandon the session. There's no error — the binding just never happens.

Refresh: re-proving possession, forever

The bound cookie is deliberately short-lived (ten minutes in the reference flow). When it expires, the browser refreshes the binding before it replays whatever request the user was making. This is the heartbeat that makes a stolen cookie useless.

sequenceDiagram
    participant TPM as Hardware key store
    participant Browser
    participant Server
    Note over Browser: bound cookie expires
    Browser->>Server: POST /dbsc/refresh<br/>Sec-Secure-Session-Id: <sessionId>
    Note right of Server: no proof yet
    Server-->>Browser: 403 + Secure-Session-Challenge: "<new jti>"
    Browser->>TPM: sign the new challenge
    TPM-->>Browser: signature
    Browser->>Server: POST /dbsc/refresh<br/>Secure-Session-Response: <JWS>
    Server->>Server: verify against stored key
    Server-->>Browser: 200 + fresh cookie + JSON config
    Browser->>Server: replay the user's original request

Two things in here are easy to get wrong and silent when you do.

First, the session is identified by the Sec-Secure-Session-Id header, not by a cookie — because the bound cookie has already expired by the time refresh runs. If you try to read the session from a cookie here, there's nothing to read.

Second, that first response must be 403, not 401. The 403 with a Secure-Session-Challenge header is the signal that makes Chromium sign and retry. A 401 — which feels like the "more correct" status for "you haven't proven who you are" — is silently ignored, and the session quietly dies. This one cost me a full day of staring at a session that just stopped refreshing with no error anywhere.

The refresh JWS is the same as the registration JWS with one difference: it carries no embedded jwk. The server already has the public key from registration, so the browser just signs the new challenge with the same private key. A refresh JWS that does include a jwk is a protocol error.

The security payoff lives in the failure path. If the signature doesn't verify — which is exactly what happens when an attacker replays a stolen cookie from their own machine, because their machine has no matching key — the server demotes the session to tier: none and rejects it. The stolen session is dead. The real browser, with the real key, sails through the same refresh.

What the tier means

After all this, the server exposes one value to the application: the session's tier.

Tier	Bound by	Key lives in	Defeats
`dbsc`	Native protocol, signature verified	Hardware (TPM / Secure Enclave)	Remote cookie theft and on-device malware reading the profile
`bound`	Web Crypto polyfill, signature verified	Non-extractable key in browser storage (IndexedDB)	Remote cookie theft. Not on-device malware.
`none`	Nothing bound, or a refresh failed	—	Nothing a bare cookie doesn't already

The bound tier exists because native DBSC is Chromium-only today — Firefox and Safari don't speak it. A Web Crypto polyfill does the same binding with a non-extractable key in IndexedDB. It's a notch weaker (the key is in browser storage, not a separate chip, so it doesn't stop malware with disk access on the user's own machine) but it defeats every remote replay, which is the threat that matters at scale. The point is that the application reads one tier field and doesn't care which protocol produced it.

The piece most explanations skip: per-request proofs

Session-level binding (registration + refresh) leaves a small window: between two refresh cycles, a freshly stolen cookie is still valid because the next signature check hasn't happened yet. To close that, a server can demand a proof on individual sensitive requests, not just on refresh:

X-Dbsc-Bound-Proof: ts=<timestamp>;sig=<signature>;bh=<body hash>

The client signs <sessionId>.<METHOD>.<path>.<timestamp>.<bodyHash> with the bound key. A guarded route verifies that signature before doing anything sensitive. A request riding a stolen cookie from another device can't produce the signature — there's no key on that device — so it's rejected on the first guarded request, not after the next refresh.

One subtlety here is the reason Chromium sessions carry two keys. The hardware key signs refresh challenges, but by design it's never exposed to JavaScript, so it can't sign an arbitrary request message. So a Chromium session co-registers a second, software (polyfill) key specifically for per-request proofs. The route guard always checks that bound key, which is why the same guard works identically on Chrome, Firefox, and Safari.

What DBSC does not do

Being precise about this is what separates understanding the protocol from cargo-culting it:

It does not stop malware running inside the browser process. If the attacker is the browser, they get the live session like the user does.
The bound (polyfill) tier does not stop infostealer malware with read access to the browser profile on disk. Only the native dbsc tier, with the key in a TPM or Secure Enclave, does.
It does not replace authentication. A session already exists before DBSC binds it; DBSC protects the session, it doesn't establish identity.

I wrote a whole separate piece on the threat boundary because it's the part security engineers care about most and the part marketing copy always blurs.

Why this matters now

DBSC is the first session-security primitive in a long time that moves the bearer-token problem instead of just shrinking it. SameSite, Secure, HttpOnly, short TTLs — all of those reduce the blast radius of a stolen cookie. DBSC makes the stolen cookie not work. And as of Chrome 146 it's in stable, which means it's no longer a research demo — it's something you can turn on for real users.

If you want to implement the server side, the full wire contract is written up as a language-neutral spec with round-trip test vectors, and there's a Node reference implementation (dbsc-toolkit) verified end-to-end against Chrome 147 on real TPM 2.0 hardware. The protocol is small. The details are merciless. Both are worth knowing before you ship it.

How to Stop Stolen Session Cookies in Node.js using Device Bound Session Credentials (DBSC)

Suliman Abdulrazzaq — Sun, 24 May 2026 22:39:56 +0000

Web applications still rely heavily on session cookies — and that creates a serious security problem:

If a session cookie gets stolen (via XSS, malware, logs, or proxy leaks), it can often be replayed from another device with no resistance.

This is exactly the gap that Device Bound Session Credentials (DBSC) aims to solve.

DBSC is a W3C specification that binds a session to a device-held cryptographic key instead of treating cookies as pure bearer tokens.

In this article, I’ll show a practical Node.js implementation using dbsc-toolkit, an open-source library that brings DBSC support to real-world backend frameworks.

🔐 What DBSC Changes

Traditional cookies:

Whoever has the cookie → owns the session

DBSC model:

Session is tied to a device key (TPM / Secure Enclave / WebCrypto fallback)
Stolen cookies alone are useless on another device
Server verifies proof of device possession on requests
⚙️ What dbsc-toolkit provides

dbsc-toolkit is a Node.js implementation of DBSC with:

Session registration flow
Challenge / response verification
Session binding + validation
Express / Fastify / Hono / Next.js support
Redis / PostgreSQL / Memory storage adapters
Optional Web Crypto fallback for non-Chromium browsers
🚀 Quick Example (Express)
import express from "express";
import { randomUUID } from "node:crypto";
import { createDbsc } from "dbsc-toolkit/express";
import { MemoryStorage } from "dbsc-toolkit/storage/memory";

const app = express();
app.use(express.json());

const dbsc = createDbsc({ storage: new MemoryStorage() });
dbsc.install(app);

app.post("/login", async (req, res) => {
await dbsc.bind(res, randomUUID(), { userId: req.body.username });
res.json({ ok: true });
});

app.get("/me", (req, res) => {
res.json(res.locals.dbsc);
});

app.listen(3000);
🧪 Why this matters

Most modern auth systems still rely on bearer-based sessions (cookies or JWTs).

That means:

XSS → session theft
logs → session leakage
proxy leaks → replay attacks
malware → full account takeover

DBSC changes the model from:

"Who has the token?"

"Who owns the device that can prove the key?"

🌐 Compatibility

dbsc-toolkit works with:

Node.js (Express, Fastify, Hono, Next.js)
Chrome (native DBSC on supported versions)
Firefox / Safari (WebCrypto fallback)
Redis / PostgreSQL / Memory storage
📦 Repository

https://github.com/SulimanAbdulrazzaq/dbsc-toolkit

💬 Notes

This project is based on the current W3C DBSC specification and is intended for experimentation, prototyping, and early adoption in Node.js authentication systems.

Feedback, security review, and spec alignment suggestions are welcome.