Home / Knowledge hub / Web storage security
Knowledge hub
Web storage security
The risk of keeping tokens in localStorage, where any script on the page can read them.
What it means
Web storage is the browser's built-in key-value store: localStorage keeps data until it is cleared, and sessionStorage keeps it for one tab. Any JavaScript running on your page can read and change both. Nothing in the browser asks who is reading.
That is the whole security question. Storage has no notion of which script is yours. A tracking snippet, a compromised library or an injected script reads the same values your own code does, and sends them anywhere it likes. There is no access control inside the page, only a shared space that every script on it can open.
Why it matters
If a sign-in token lives in localStorage, one cross-site scripting flaw is enough to steal it. The attacker does not need the password, and the stolen token keeps working from their own machine until it expires or is revoked. That is a quiet loss, since nothing on the user's screen changes.
Third-party scripts widen the risk. Every analytics tag, chat widget or ad script you load runs with full access to the page. A supply chain attack on one of them becomes a theft of every token stored in the browser.
How it shows up
You meet it in single-page apps that keep a JWT or an API key in storage so that front-end code can attach it to requests. It is convenient, which is why it is common. Look for tokens, personal data and long-lived secrets saved by name in browser storage.
The usual safer choice is a session cookie marked HttpOnly, Secure and SameSite, because scripts cannot read it. That trades one risk for another, so pair it with CSRF protection. If you must use storage, keep tokens short-lived and store nothing else sensitive.
Questions people ask
Web storage security, answered
Is localStorage safe for tokens?
It is only as safe as every script on your page. If an attacker can run script there, they can read the token. For sign-in credentials, an HttpOnly cookie is generally the safer place.
Is sessionStorage safer than localStorage?
Slightly, because it clears when the tab closes and is not shared between tabs. Scripts on the page can still read it, so it does not defend against cross-site scripting.
Do cookies fix the problem?
They remove script access when set as HttpOnly, but browsers then send them automatically, which brings CSRF into play. Use SameSite and anti-forgery tokens alongside them.
What should never be stored in the browser?
Long-lived secrets, API keys with broad access, unencrypted personal data and anything that gives account access on its own. Treat browser storage as visible to the user and to any script on the page.
Does a content security policy help?
Yes, it reduces what injected script can run or send out. A content security policy limits the damage but does not make storage private from your own page's scripts.
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
JWT
A signed token a client carries to prove who is signed in.
HttpOnly cookie
A cookie that page scripts cannot read, so XSS cannot simply steal it.
Session token
A random value the browser sends to show it belongs to a signed-in visit.
Content Security Policy
A header telling the browser which scripts a page may load.
What can a script on your page read?
Token handling is tested against the running app, and in white-box mode a finding can point to the file and line that stores it. Each result comes with the request that proved it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.