A valid cookie on
a different device
Infostealers copy session cookies. The attacker skips login and goes straight to your billing settings, exports or API keys.
Decision trace
Example · sensitive actionRevoke
- Bound sessionChrome on macOS, with a known visitor and fingerprint.
- Current requestThe same valid session from a different visitor and fingerprint.
- Reason
session_device_change - DecisionRevoke the session in your backend. Queue a session.suspicious webhook.
How it works
Bind after authentication
Associate your opaque session id with the browser token, network and User-Agent.
Check before sensitive actions
Send a fresh browser token before billing, key creation, password changes or exports.
Apply the decision
Allow, require independent step-up, or invalidate the session. Review suspicious checks in the dashboard.
API
POST /v1/session
{"secret":"sk_…","event":"check","sessionId":"sess_42","accountId":"user_42","token":"BROWSER_TOKEN"}
{"decision":"revoke","reasons":["session_device_change"],"boundAt":1792800000000}Keep secrets on your backend. Raw session identifiers and IPs are never stored. Suspicious webhooks include only a session hash prefix.
Limits
- Default rules are logical and untuned against measured customer traffic. A country change within two hours challenges; a network change alone allows.
- VPN toggling, corporate proxies and mobile roaming change networks. Browser updates may change fingerprints, but version updates alone do not trigger UA changes.
- Device-key detection needs the browser token on both bind and check. An attacker with matching copied identifiers can evade it.
- Unknown sessions allow. Bind after authentication and check on every sensitive action. Only your backend can revoke its sessions.
- Bindings expire after 30 days without a check. The Node SDK fails open on transport failures.