Security What Never to Store in Storage
Avoid storing tokens or PII in localStorage.
Security What Never to Store in Storage is a free HTML Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the HTML Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Storage is Plain Text
localStorage and sessionStorage save data unencrypted on disk under the user profile. Any process with file-system access — including malware, backup tools, or another logged-in user — can read every value you stored without going through the browser.
Reachable by Any Script
All scripts running on the origin share the same Storage. A successful XSS attack, a compromised third-party SDK, or a malicious browser extension can call localStorage.getItem and exfiltrate every stored value. There is no per-script isolation.
Never Store Authentication Tokens
Do not put session tokens, JWTs, refresh tokens or API keys in localStorage. If an attacker injects a single line of JavaScript, the token leaks immediately. Use httpOnly, Secure, SameSite cookies so the token is never reachable from JavaScript.
Never Store Passwords
Storing passwords in any form — plaintext, hashed, encrypted — is wrong on the client. Hashing client-side does not help when the attacker can read the hash and replay it. Password handling belongs entirely on the server with a dedicated password hash like bcrypt.
Never Store Credit Card Data
PCI-DSS forbids storing card numbers, CVVs, magnetic stripe data or expiration dates in client storage. Use a tokenized payment provider (Stripe, Braintree, Adyen) that returns a short-lived token bound to your origin instead.
Never Store Personal Identifiers
Government IDs, full birth dates, home addresses and medical data attract regulators (GDPR, HIPAA) and attackers. Store only what is required for the current session, request it again when needed, and let the server keep the source of truth.
XSS Multiplies the Damage
An XSS bug that leaks document.cookie is bad. The same bug on a page that stores tokens in localStorage hands the attacker every stored value at once. Treat localStorage as a "you compromised one script, you compromised everything" surface.
Encryption Does Not Save You
Encrypting values with a key that also lives in JavaScript provides no real protection — the attacker who can read the ciphertext can read the key too. Real secrets need to stay server-side and be re-issued, never persisted client-side.
Safe Things to Store
UI preferences (theme, sidebar collapsed, language), non-sensitive feature flags, draft form contents and ephemeral wizard state are all fine. They are user-visible anyway and leaking them does not enable account takeover.
localStorage.setItem("theme", "dark");
localStorage.setItem("sidebar:collapsed", "true");
localStorage.setItem("draft:post-123", draftMarkdown);Use Cookies for Auth
Issue authentication via Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. The HttpOnly flag makes the cookie unreachable to JavaScript, which neutralizes most token-stealing XSS payloads even when other bugs exist on the page.
Mitigations Around Storage Use
If you must cache sensitive-looking data, scope it tightly (short TTL, clear on logout, remove on tab close via sessionStorage), apply a strict Content Security Policy to block injected scripts, and audit every third-party script that runs on authenticated pages.
Knowledge Check
Why are authentication tokens stored in localStorage considered a security risk?
Summary
Web Storage is plain-text, script-readable, and per-origin shared. Never put authentication tokens, passwords, payment data or regulated personal information there. Keep secrets in httpOnly cookies and reserve localStorage for harmless UI state that the user could see anyway.
Frequently asked questions
Is the “Security What Never to Store in Storage” lesson free?
Yes — the full text of “Security What Never to Store in Storage” is free to read here on the web, and the HTML Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the HTML Academy course, upgrade to CoddyKit PRO.
What will I learn in “Security What Never to Store in Storage”?
Avoid storing tokens or PII in localStorage. You practise HTML Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start HTML Academy?
No prior experience is required. HTML Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Security What Never to Store in Storage” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this HTML Academy lesson?
Yes. Every HTML Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- localStorage vs sessionStorage
- Getting Setting and Removing Items
- Listening for Storage Events
- Security What Never to Store in Storage