Q237: Secure Browser Storage, Cookies and Token Handling

What Interviewers Want To Evaluate

Interviewers want to know whether you understand storage trade-offs for frontend security and user experience.

They check cookies, localStorage, sessionStorage, IndexedDB, HttpOnly, Secure, SameSite, token storage, XSS, CSRF, refresh tokens, sensitive data, and how storage choices affect performance and offline behavior.

Short Interview Answer

I avoid storing high-value tokens in JavaScript-readable storage because XSS can read localStorage, sessionStorage, and IndexedDB. For web sessions, I prefer secure HttpOnly cookies with Secure and SameSite attributes when the architecture supports it. Client storage is useful for low-risk preferences, drafts, caches, and local progress, but sensitive data should be minimized, scoped, expired, and protected by server-side validation.

Detailed Interview Answer

Browser storage is not one thing.

Each option has different security and UX trade-offs.

Common storage types:

cookies
localStorage
sessionStorage
IndexedDB
Cache Storage
memory

The first question is what kind of data is being stored.

Data Classification

Classify data before choosing storage.

high-risk: access tokens, refresh tokens, session secrets
personal: profile data, email, preferences
medium-risk: drafts, private content metadata
low-risk: theme, local reading progress, UI layout
cacheable: public assets and public API responses

Sensitive data should have the least exposure possible.

localStorage Risk

localStorage is easy to use.

It is also readable by JavaScript.

If an XSS bug exists, an attacker can read it.

This makes localStorage a poor place for high-value tokens.

Good localStorage uses:

theme preference
non-sensitive UI state
local reading progress
dismissed banner state

Avoid storing secrets there.

sessionStorage

sessionStorage is scoped to a tab session.

It is still JavaScript-readable.

It reduces persistence but not XSS exposure.

Use it for temporary non-sensitive state.

Do not treat it as secure secret storage.

IndexedDB

IndexedDB supports larger structured storage.

Useful for:

offline data
large caches
drafts
client-side databases
search indexes

But it is also accessible to JavaScript from the origin.

Sensitive data still needs careful treatment.

Cookies

Cookies can be configured with security attributes.

Important flags:

HttpOnly
Secure
SameSite
Path
Domain
Expires or Max-Age

HttpOnly prevents JavaScript access.

Secure requires HTTPS.

SameSite helps reduce CSRF risk.

HttpOnly Session Cookies

For many web apps, HttpOnly secure cookies are a strong session mechanism.

Benefits:

not readable by JavaScript
automatically sent to same-site requests
works with server-side authorization
can be scoped and expired

Trade-off:

CSRF must be considered
cross-site auth flows need care
server must validate session
cookie size is limited

SameSite

SameSite options:

Strict
Lax
None

Lax is a common default for many web sessions.

None requires Secure and is used for cross-site contexts.

Choose based on product flow.

Token Handling

Avoid casual token storage.

Ask:

who can read it
how long does it live
can it be rotated
is refresh token exposed
what happens on logout
what happens after XSS
what happens after device sharing

Short-lived access tokens reduce damage.

Refresh tokens need stronger protection.

Performance Considerations

Storage can affect performance.

Examples:

large localStorage reads are synchronous
IndexedDB is async but more complex
cookie size is sent with requests
large caches consume memory and disk

Do not store large data in cookies.

Every request may carry that cost.

Common Mistakes

Common mistakes include:

storing long-lived tokens in localStorage
forgetting HttpOnly or Secure cookie flags
using SameSite=None without understanding cross-site exposure
storing large data in cookies
not clearing storage on logout
keeping sensitive drafts forever
assuming client storage is trusted

Client storage is controlled by the client.

The server must remain authoritative.

Senior Trade-Offs

Storage decisions balance:

security
UX persistence
offline support
performance
implementation complexity
cross-device behavior

The answer should start with data sensitivity.

Interview Framing

In an interview, say:

I choose browser storage based on data sensitivity. Secrets should not live in JavaScript-readable storage; session cookies should use HttpOnly, Secure, and SameSite; client storage is better for low-risk preferences, drafts, and caches.

Revision Notes

• JavaScript-readable storage is exposed to XSS.
• HttpOnly cookies protect against token theft through JavaScript.
• SameSite helps reduce CSRF risk.
• Cookies should not store large payloads.
• IndexedDB is useful for offline data but not secret by default.
• Server-side authorization must remain authoritative.

Follow-Up Questions

• Why is localStorage risky for tokens?
• What does HttpOnly do?
• How does SameSite help?
• When would you use IndexedDB?
• Why can large cookies hurt performance?

How I Would Answer This In A Real Interview

I would say storage choices start with sensitivity. I would not put long-lived high-value tokens in localStorage because XSS can read them. I would prefer HttpOnly Secure SameSite cookies for sessions where possible, keep server-side authorization authoritative, and use client storage for low-risk preferences, progress, drafts, or offline caches with clear expiry and cleanup.