What breaks when JWTs are stored in local storage or session storage?

Why This Matters for Security Teams

JWTs in NIST SP 800-53 Rev 5 Security and Privacy Controls terms are not just a browser storage choice. They are a trust boundary decision. When a token is readable by JavaScript, any successful XSS payload can copy it and replay it elsewhere, turning a front-end bug into account takeover. The risk is sharper for long-lived access tokens, because the attacker can keep using the token until it expires or is revoked.

NHI Management Group has shown how often identity material becomes the real blast radius in compromise cases, especially when secrets and API keys are exposed outside managed controls. That pattern is visible in incidents such as the Google Firebase misconfiguration breach and the Microsoft Azure Key Breach, where exposed credentials turned configuration mistakes into wider abuse. The same logic applies to JWTs stored where scripts can read them. In practice, many security teams encounter token theft only after an XSS payload has already been executed and the session has already been reused from another location.

How It Works in Practice

Local storage and session storage fail differently, but the core weakness is the same: both are script-accessible. If an attacker can inject JavaScript, the token can be read, copied, and exfiltrated. Local storage keeps the token across browser restarts, so compromise persists longer. Session storage limits persistence to the tab or browser session, but it still offers no protection against an active script running in the page.

Practitioners often assume that “short-lived JWT” alone solves the problem. It helps, but only if token lifetime is genuinely short and the application can tolerate frequent reauthentication. Better patterns usually combine several controls:

• Keep access tokens out of browser storage where possible and prefer least-privilege, bounded-session controls.
• Use httpOnly, Secure, SameSite cookies for browser sessions when the application model allows it.
• Set short token TTLs and rotate refresh tokens carefully, with server-side revocation support.
• Harden against XSS with output encoding, CSP, input validation, and dependency hygiene.
• Track token reuse, impossible travel, and abnormal session patterns as abuse signals.

For NHI-heavy environments, the same principle applies to service tokens and browser-adjacent automation: if JavaScript can see it, attacker-controlled scripts can see it too. That is why NHI Management Group guidance emphasizes reducing the time secrets remain valid and keeping them out of exposed locations whenever possible, especially in identities that sit close to web application traffic. These controls tend to break down when single-page applications require aggressive client-side state handling because teams trade convenience for exposure without a compensating revocation strategy.

Common Variations and Edge Cases

Tighter browser session controls often increase implementation complexity, requiring organisations to balance user experience against token theft resistance. That tradeoff is real, especially in SPAs, embedded apps, and cross-domain SSO flows where cookie handling or CSRF protections are harder to configure cleanly.

Current guidance suggests there is no universal standard for every front-end architecture, but some edge cases are clear. Session storage is marginally better than local storage only in persistence, not in resistance to XSS. Refresh tokens in browser storage are especially dangerous because they extend the attacker’s window far beyond a single API call. If a product depends on “remember me” behavior, the safer pattern is often server-managed session state with strong reauthentication triggers rather than persistent client-side token caches.

Teams should also treat token theft as an identity governance issue, not only a web security issue. Broader NHI controls such as inventory, rotation, and revocation discipline matter because a stolen JWT behaves like any other compromised secret once it leaves the browser. That is why compromise patterns discussed in the Ultimate Guide to NIs map directly to browser token abuse: the failure is not storage alone, but the combination of exposure, privilege, and delayed invalidation.

Related resources from NHI Mgmt Group

• Why are local .env files and config notes risky in Microsoft 365?
• What breaks when session tokens are stored insecurely?
• What breaks when an AI browser can read local files inside a user session?
• What breaks when conversation state is spread across local storage, proxies, and external model calls?