Topic starter
19/08/2026 3:47 pm
TL;DR: JWTs are widely used for application authentication, but insecure browser storage can expose tokens to XSS, CSRF, and extension-based theft, according to Descope’s developer guide. The core issue is not token format but where the token lives, because storage choice directly changes the compromise path and revocation options.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “The Developer’s Guide to JWT Storage”.
Key questions
Q: What breaks when JWTs are stored in local storage or session storage?
A: The main failure is script readability.
Q: When should teams prioritise HttpOnly cookies over local storage for JWTs?
A: Teams should prioritise HttpOnly cookies when reducing direct JavaScript access matters more than avoiding CSRF complexity.
Q: What are the signs that browser JWT storage is failing in practice?
A: Warning signs include tokens surviving far longer than intended, refresh logic that hides stale sessions, repeated reliance on local storage for convenience, and authentication flows that cannot explain how revocation works.
Practitioner guidance
- Review JWT storage against the dominant theft path Map whether XSS, CSRF, extension access, or cross-domain flow is the most realistic exposure route for your application, then choose storage around that route rather than defaulting to local storage.
- Use HttpOnly, Secure, and SameSite together If cookies carry the token, require HttpOnly, Secure, and SameSite and pair them with anti-CSRF protections so the browser cannot silently turn authentication into request forgery.
- Shorten token lifetime and rotate aggressively Reduce the time a stolen JWT remains useful by keeping browser tokens short-lived and tying renewal to explicit refresh handling and revocation checks.
Bottom line: JWTs become a browser security problem when storage choices make tokens easy to steal and replay.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:24 pm
JWT storage is part of the authentication control plane, not a frontend preference. The moment a bearer token is placed in the browser, the application inherits the browser’s exposure model, including script access, extension access, and cross-site request behaviour. That means session design, token lifetime, and storage method must be governed together, not reviewed as separate layers. Practitioners should treat browser token placement as an IAM decision with direct compromise consequences.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should security teams handle JWT revocation after browser compromise?
A: Teams should assume the stolen token can be replayed until expiry unless revocation is enforced server side. That means revocation checks, short token lifetimes, and session invalidation paths must be designed before the browser storage decision is finalised.
👉 Read our full editorial: JWT storage choices expose the browser attack surface