Session or token theft

Detection signals

• The same session or token used from two distant locations or devices
• API calls with a valid token but anomalous IP, device, or behavior
• Refresh tokens used after the user logged out
• Tokens appearing in logs, error reports, or public paste sites

Likely root causes

• XSS or a malicious dependency exfiltrating tokens from the browser
• Tokens stored insecurely (localStorage, logs, URLs)
• A leaked signing key allowing token forgery
• Overly long token lifetimes with no rotation

Containment

1. 1Revoke the affected sessions and refresh tokens immediately
2. 2If a signing key may have leaked, rotate signing keys to invalidate all tokens
3. 3Force re-authentication for affected users
4. 4Patch the exfiltration vector (fix XSS, remove the malicious dependency)

Customer communication

• Notify affected users and require re-authentication
• If a signing-key rotation logs everyone out, post a brief status note
• Explain what was accessible with the stolen token

Forensics & logging

• Trace actions taken with the stolen token via audit logs
• Identify the exfiltration vector (client-side vs server-side)
• Preserve tokens and logs as evidence before rotation

Post-incident hardening

• Shorten access-token lifetimes; rotate refresh tokens on use
• Store tokens in HttpOnly, Secure cookies; never in localStorage or URLs
• Add token binding / sender-constrained tokens (DPoP or mTLS) where supported

FAQ

How do I contain a stolen session or token?

Revoke the affected sessions and refresh tokens immediately, and if a signing key may have leaked, rotate signing keys to invalidate all tokens. Then patch the exfiltration vector (fix the XSS, remove the bad dependency).

How do I stop token theft recurring?

Shorten access-token lifetimes and rotate refresh tokens on use, store tokens in HttpOnly Secure cookies (never localStorage), and add sender-constrained tokens (DPoP or mTLS) where supported.