intermediate

Storage security

Choose cookie, memory, Web Storage, IndexedDB, or Cache Storage based on sensitivity, lifetime, and XSS risk.

Client storage choices depend on sensitivity, lifetime, access pattern, and attacker model. Memory is short-lived but lost on reload, cookies can be HttpOnly but are automatically sent, Web Storage is simple but exposed to XSS, and IndexedDB or Cache Storage can persist large data that must be invalidated safely.

| Store | XSS readable | Auto-sent on requests | Typical use | |-------|--------------|----------------------|-------------| | Memory | Yes | No | ephemeral UI state | | HttpOnly cookie | No (JS) | Yes | session id | | localStorage | Yes | No | small prefs | | IndexedDB / Cache | Yes | No | offline data |

On interviews: security-first answer, not only capacity comparison between storage mechanisms.

Common pitfalls: putting access tokens in localStorage makes XSS a session theft. Persistent caches can leak previous-user data on shared devices.

The trade-off is convenience versus control — pick the mechanism that matches your coupling and performance budget.

Checklist:

  • Classify data sensitivity first.
  • Minimize lifetime and scope.
  • Plan logout and cache invalidation.
  • Defense in depth against XSS.