Local Storage is a web storage API allowing websites to store key-value pairs in a browser with no expiration time. While convenient for client-side data persistence, it requires careful security consideration as stored data is accessible to any JavaScript running on the origin. Sensitive data should be encrypted, and input must be validated to prevent XSS attacks.
Local Storage is a Web Storage API that lets a site keep string key-value pairs in the browser with no expiry, scoped to a single origin (protocol plus host plus port). Data written by pages.example.com is readable only by that same origin, and it survives tab closes, page reloads, and browser restarts until code or the user clears it. Access is synchronous through window.localStorage, so reads and writes block the main thread and the practical size limit is roughly 5 to 10 MB per origin. Unlike cookies, the contents never travel with HTTP requests, which keeps request headers small but also means the server never sees or controls what a page stores there.
The critical property is that any JavaScript running on the origin can read every Local Storage key. There is no HttpOnly equivalent, so a single cross-site scripting flaw, or one compromised third-party script, can enumerate the store and exfiltrate whatever it finds. Because of this, session tokens, JWTs, API keys, or personal data stored here are far more exposed than the same value in an HttpOnly cookie, which script cannot read. Values also persist indefinitely, so a token stolen weeks after login can still be valid. Local Storage offers no encryption, no integrity checks, and no automatic expiry, making it a poor vault for anything an attacker would want.
Treat Local Storage as public to any code on the page. Keep authentication tokens in HttpOnly, Secure, SameSite cookies rather than storage that JavaScript can read, and store only non-sensitive, low-value data locally. Sanitize and validate anything read back before inserting it into the DOM, since attacker-controlled values retrieved from storage can drive DOM-based XSS. A strict Content Security Policy limits which scripts can run and therefore who can touch the store. cside is relevant to the third-party-script side of this: by routing external scripts through a Script method and analysing the payload, it can detect and block a vendor script that starts reading storage and exfiltrating it.
Not for secrets. Local Storage is never sent with requests, which avoids some CSRF exposure, but every script on the origin can read it, and it cannot be marked HttpOnly. An HttpOnly cookie is invisible to JavaScript, so for session tokens a well-configured cookie is the safer choice.
No. Local Storage is partitioned by full origin, so app.example.com and shop.example.com have separate, isolated stores and cannot read each other's data. Cookies can be shared across subdomains via the domain attribute, but Local Storage has no equivalent mechanism.
We answer client-side security questions every day. Bring yours.