Browser Storage APIs
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep, eslint, and lighthouse — these are specialist/SAST tools that can detect patterns like JWT tokens in localStorage or missing cookie flags. They are not default linters (which would be d3), but dedicated tools that must be configured to catch this pattern.
Closest to 'simple parameterised fix' (e3). The quick_fix describes a clear replacement pattern: swap localStorage for sessionStorage or HttpOnly cookies depending on use case. This is a targeted find-and-replace refactor within the storage layer — not a one-liner (e1) but not multi-file architectural rework either.
Closest to 'localised tax' (b3). The applies_to scope is web contexts only, and the burden falls on the storage/auth layer of a given application. It doesn't reshape the entire codebase, but the wrong storage choice for auth tokens can require revisiting auth flows in one component area.
Closest to 'serious trap' (t7). The misconception field directly states the canonical wrong belief: 'localStorage is a safe place to store authentication tokens.' This contradicts how many developers reason about storage (treating it like a secure server-side store), and the 'obvious' approach of storing JWTs in localStorage is exactly the insecure one. This is a well-documented gotcha that contradicts reasonable analogies from other storage paradigms.
Also Known As
TL;DR
Explanation
localStorage: synchronous key-value store, persists until cleared, ~5MB, same-origin only — suitable for user preferences and non-sensitive settings. sessionStorage: same API, cleared when tab closes — suitable for single-session state. Both are accessible to JavaScript on the same origin, making them vulnerable to XSS attacks — never store tokens or sensitive data. IndexedDB: asynchronous, structured, transactional, gigabytes of capacity — for offline apps and caching large datasets; use a wrapper library (Dexie.js) to avoid verbose raw API. Cookies: sent to server on every request, support HttpOnly (JS-inaccessible), Secure, SameSite, and domain/path scoping — the correct storage for session tokens. Cache API (Service Workers): for offline asset caching. PHP sets HttpOnly cookies server-side, making them invisible to JavaScript and XSS-resistant.
Common Misconception
Why It Matters
Common Mistakes
- Storing JWT tokens or session tokens in localStorage — XSS can steal them via document.cookie-equivalent access.
- Not setting HttpOnly and Secure flags on sensitive cookies — accessible to JavaScript and sent over HTTP.
- Using localStorage for data that should expire with the browser session — use sessionStorage instead.
- Not considering that localStorage is synchronous and blocking — large reads/writes freeze the main thread.
Code Examples
// Storing session token in localStorage — accessible to XSS
localStorage.setItem('auth_token', token);// Session tokens: use HttpOnly cookie (server sets it, JS can't read it)
// Set-Cookie: session=...; HttpOnly; Secure; SameSite=Strict
// localStorage is fine for non-sensitive preferences
localStorage.setItem('theme', 'dark');
localStorage.setItem('language', 'en');
// sessionStorage for single-tab state (form wizard progress)
sessionStorage.setItem('checkout_step', '2');