A web storage mechanism that keeps data available to scripts running in the same origin. For identity teams, this is risky for tokens and session material because any script execution in that origin can read the stored value and reuse it as proof of access.
What browser local storage is used for
Browser local storage is a simple client-side persistence layer for origin-scoped values, often used for preferences, flags, cached state, and other data a page expects to survive refreshes or browser restarts.
Its appeal is convenience: scripts can read and write values without a round trip to a server, which makes it attractive for lightweight web app state. That same convenience also makes it a poor place for anything that should be tightly protected from in-origin script access.
Why local storage behaves differently from cookies and session memory
Local storage is available to scripts running in the same origin, so it follows the security boundary of the page itself rather than an isolated browser secret store. If code in that origin executes, it can usually inspect stored values directly.
That design difference matters because local storage is not a browser-side trust boundary. It does not provide confidentiality against script execution inside the origin, and it does not add meaningful protection if the page is exposed to cross-site scripting or malicious third-party script.
Why tokens and session material are especially sensitive here
Using local storage for access tokens, refresh tokens, or session material increases blast radius if the origin is compromised. A script that can run in the page context can often extract those values and reuse them outside the browser session.
For identity teams, the key issue is not storage convenience but replay risk. When a value functions as proof of access, storing it where any same-origin script can read it turns script execution into credential exposure.
That is why browser local storage is usually better suited to non-sensitive application preferences than to secrets, authentication material, or durable login state. In security design terms, it is a convenience cache, not a protected vault.
How to think about local storage in application design
Local storage is best treated as attacker-readable if the page origin is compromised. That framing helps teams decide whether the data belongs there at all, and whether the application can tolerate disclosure or replay.
Where data is low risk and user experience matters more than protection, local storage can be reasonable. Where the value represents session authority, long-lived access, or anything that grants downstream privilege, the safer pattern is to keep that material out of script-readable storage and rely on stronger browser and server-side session handling.
Risk and Threat Considerations
Local storage becomes risky when developers place tokens, session material, or other proof-of-access values into a location any same-origin script can read. The main hazard is that one successful script injection or compromised third-party script can expose durable access material at scale.
Failure mechanism: If an attacker gains script execution in the origin, they can read local storage directly and reuse any stored token or session value, turning a page compromise into account or session compromise.
Impact: This can lead to credential theft, session replay, unauthorized API access, and broader account takeover if the stolen value is still accepted by backend services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V9 — Self-contained Tokens | Local storage often holds bearer-like token material. |
| Recommendation — Keep self-contained tokens out of script-readable storage when disclosure would enable reuse. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The term concerns storage and handling of authentication material. |
| Recommendation — Manage token and session lifecycles so reusable authenticators are minimized and revoked promptly. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Browser-stored session material affects authenticator handling and replay resistance. |
| Recommendation — Prefer phishing-resistant and replay-resistant session designs over script-readable browser persistence. | ||
Practitioner Guidance
Why practitioners should care: Treat local storage as suitable for low-sensitivity state only. If a value would be damaging to disclose or replay, do not store it where in-origin script can access it.
Common misunderstanding: Many teams assume browser persistence implies browser protection. In reality, local storage protects convenience, not confidentiality, and it should not be used as a substitute for secure session design.
Practitioner takeaway: The deciding question is not whether local storage is easy to use, but whether the stored value remains safe if any script in the origin can read it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org