In today’s blog, we’ll take a look at what can make web storage a security liability and how to lock it down to secure your web applications. These are vulnerabilities we often discover during penetration tests here at Raxis. Let’s take a look at why we consider them worthy of your attention and your team’s remediation.
How Attackers Exploit localStorage and sessionStorage
1. XSS Attacks: Stealing Data Through JavaScript Injection
Since localStorage and sessionStorage properties are fully accessible to JavaScript, a successful Cross-Site Scripting (XSS) attack can steal stored authentication tokens, user data, or encryption keys in web storage. Unlike HTTP-only cookies, web storage has no built-in protection against script-based theft.
Real-world risk:
A vulnerable comment form allows an attacker to inject malicious JavaScript that exfiltrates all sessionStorage data—compromising every user who visits the page.
2. Session Hijacking on Shared or Public Devices
While sessionStorage clears when the browser closes, restored sessions (e.g., after a crash) can leave temporary data exposed. For localStorage, which persists indefinitely, failing to clear data on logout means data remains accessible.
Example scenario:
A user logs out of a banking app but doesn’t clear localStorage. An attacker with access to the same device can steal their session token.
3. Hidden Dangers of Serialized Data in localStorage
JSON objects and other types of serialized data are often placed in localStorage without first being sanitizing, which may leak internal API keys, debug tokens, or sensitive metadata contained in nested fields during XSS attacks or if logged by external services.
Example of accidental exposure:
localStorage.setItem("userProfile", JSON.stringify({
name: "John Doe",
preferences: { theme: "dark" },
//…many key/value pairs later…
session: { debugToken: "DEV-ADMIN-KEY" } // Leaked in an XSS attack
}));An attacker extracting this data could escalate privileges or access internal assets using the exposed debugToken.
4. Cross domain Takeovers: How One Weak Link Compromises All Storage
Web storage is shared across subdomains (e.g., app.example.com and support.example.com). If a less-secure subdomain gets hacked, attackers can steal data stored by other subdomains.
Attack path:
An XSS flaw in blog.example.com lets attackers steal auth tokens stored by app.example.com in localStorage.
5. Debugging Gone Wrong: How Logs Leak Sensitive Storage Data
Developers often log localStorage for debugging, but if logs end up in Sentry, Splunk, or CI/CD pipelines, they can expose:
- Test credentials
- Unfiltered user data
- Internal keys
Breach scenario:
A logging script captures localStorage containing a developer’s admin test token. An attacker accessing the logs pivots to production systems.
How to Secure Web Storage: Best Practices
Since web storage can be risky, follow these mitigation strategies to minimize exposure:
✅ Prevent XSS at All Costs
- Enforce a strict Content Security Policy (CSP) to block unauthorized scripts.
- Use HTTP-only, Secure, and SameSite cookies for session tokens instead of web storage.
✅ Treat Web Storage as Public Data
- Never store authentication tokens, API keys, or secrets in localStorage or sessionStorage.
- Encrypt sensitive data before storing it.
✅ Enforce Strict Data Hygiene
- Auto-clear localStorage on logout or after inactivity.
- Sanitize serialized data by stripping internal fields before storage.
✅ Isolate Subdomains and Lock Down Logs
- Host critical apps on separate domains (e.g., app.example.com vs. blog.example.com).
- Create a policy prohibiting localStorage logging in production and use synthetic test data instead.
✅ Audit and Monitor for Exposure
- Scan for accidental secrets in storage (e.g., with GitGuardian or TruffleHog).
- Regularly audit your web properties using both automated and manual testing.
Final Takeaway: Web Storage Is Convenient—But Exercise Caution
While localStorage and sessionStorage simplify client-side persistence, they’re not designed for sensitive data. By assuming web storage will be compromised – and enforcing encryption, XSS protections, and strict data policies – you can reduce the risk of breaches, session hijacking, and unintended leaks.
If you enjoyed this blog, take a look at Adam’s blog on the OWASP Top 10 to see other key issues found on web application penetration tests.
