Does your browser support DBSC?
Device Bound Session Credentials have no JavaScript API, so this cannot be feature-detected. The only way to know is to serve the registration header and see whether your browser signs it. That is exactly what this page just did.
Sponsored by Report URI
Testing your browser…
Waiting to see whether a signed registration arrives.
Why you might see this
A negative result means no registration attempt arrived within the timeout — not that DBSC is impossible here.
Reload the page once before believing it. If you typed the address, Chrome may have loaded this page speculatively before you opened the tab, and a speculative load can run the whole test out before anyone is watching it. Use the browser's reload: it continues this probe and keeps the timeline. Run the test again deliberately does the opposite — it revokes the session and starts from nothing. If a reload does not change the answer, the causes below are the usual ones, most likely first:
- The browser isn't Chromium-based. Chrome is currently the only implementation.
- The device key store is out of signing quota. Signing is rate limited and the budget is shared across the whole browser, not per site, so testing DBSC repeatedly can exhaust it — after which registration fails before any request is sent and a perfectly capable browser looks exactly like one with no support. It recovers on its own; give it a while and try again.
- DBSC isn't enabled in this build. Try
chrome://flags/#enable-bound-session-credentials. - The platform has no supported key store, so Chrome has nowhere to bind a key.
- An enterprise policy turned it off —
BoundSessionCredentialsEnabled. - An extension, proxy or corporate middlebox stripped the response header.
Only your browser knows which of these it is — when registration fails, nothing reaches this server at all, so we genuinely cannot tell an unsupported browser from one that declined to sign. Chrome will tell you: open DevTools → Application → Device bound sessions, pick this site, and read the Event result for the most recent entry.
What this page sent you
A single response header on the page you are reading. Everything else follows from it.
…
What your browser sent back
Your browser generated a key pair, signed the challenge with the private half, and
POSTed this JWT to /dbsc/register. The private key never left your device.
Header
…
Payload
…
Raw
…
Your device key
The public half, as the server now holds it. DBSC carries no attestation, so this page cannot prove the private key is in a TPM or secure enclave — only that your browser holds it and can sign with it.
Public key (PEM)
…
What the server replied
The session instructions: which cookie is bound, what scope it covers, and where to refresh it. Your browser is enforcing this right now.
…
The bound cookie on ordinary requests
A plain fetch() to this origin. In a real application this is where the
enforcement gate runs — a request without a valid bound cookie is a stolen-cookie signal.
Watch a real refresh
The bound cookie lasts 180 seconds, and the first request after that makes your device sign for a new one. Leave this tab open and you will see it happen; the countdown below is honest. Both the cookie and the challenge change every time, and re-issuing either one unchanged makes the browser treat it as no refresh at all.
A real deployment would use five minutes. Signing is rate-limited, so a cookie short
enough to refresh faster than the budget refills gets quota_exceeded
back, and the session stops refreshing for good.
Waiting for the first refresh…
Protocol timeline
Every request this probe saw, in order, timed from the page load.
What we saw about your request
Useful when the answer is no, and you want to say why in a bug report.
Questions
Can DBSC support be detected with JavaScript?
No. Device Bound Session Credentials has no JavaScript API — it is driven entirely by HTTP headers, so there is no object to feature-detect. The only way to know is for a server to send a Secure-Session-Registration header and observe whether the browser answers with a signed registration. That is what this page does.
Which browsers support DBSC?
Chrome is currently the only browser that implements DBSC. It is generally available in Chrome on Windows, and support has since landed on macOS. Firefox and Safari have no implementation. Availability also depends on the device having a key store Chrome can bind to, and enterprise policy can turn it off, so the only reliable answer for a given browser is to test it.
What is DBSC?
Session cookies are bearer tokens: whoever holds one is the user, which is why infostealer malware steals them by the million and why multi-factor authentication does not help — the theft happens after the login. DBSC binds the session to a private key generated on the device, ideally in hardware. The cookie that matters becomes short-lived, and renewing it requires a signature from that key, so a copied cookie is worthless within minutes.
Does this prove my key is in a TPM or secure enclave?
No. DBSC carries no attestation, so a server cannot tell hardware-backed keys from software ones. This page can show you the public key your browser generated and prove it can sign with the private half, but not where that private half is kept.
Does turning DBSC on risk locking users out?
No. A browser that does not support DBSC ignores the registration header and carries on with normal cookie authentication, so enabling it cannot lock anyone out. That is also why support has to be detected by observation rather than by asking.
For the longer version, Scott Helme's Device Bound Session Credentials: making stolen cookies useless walks through what the protocol does and why it matters, and the W3C specification is the authority.
Is anything kept?
No. Each visit mints a throwaway probe id, and its key material and timeline are deleted within the hour. No IP addresses are logged, nothing is shared, and the device key shown above is a public key your browser generated for this page alone.