Where to Store JWT on Client Side – Security Tradeoffs
Fast recall
Quick revision
Core answer
localStorage or sessionStorage because injected JavaScript can read and export them. An access token kept only in memory has less persistence but active malicious script can still use it. A Secure, HttpOnly cookie prevents JavaScript from reading the credential, but the browser sends it automatically, so the server must use CSRF defenses and a suitable SameSite policy. For many browser apps, a backend-for-frontend that keeps OAuth tokens server-side and exposes only a hardened session cookie gives the browser the least token access.Interview-ready guide
Interview answer
There is no universally best place to store a JWT in a browser because each choice moves risk. A bearer token in localStorage or sessionStorage is easy for client code to use, but injected JavaScript can read and export it. Keeping an access token only in memory reduces persistence across reloads, although active malicious script can still call the API while the page is open.
A Secure, HttpOnly cookie prevents JavaScript from reading the credential value. That helps against token exfiltration, but the browser sends the cookie automatically, so unsafe requests need CSRF protection and an appropriate SameSite policy. HttpOnly also does not stop injected script from performing actions through the trusted page.
For many browser applications, a backend-for-frontend is a strong design: OAuth tokens remain on the server and the browser receives only a hardened session cookie. That cookie still needs CSRF protection. The final choice depends on whether the client is a browser or native app, the origin layout, persistence needs, XSS exposure, and how renewal and logout must work.
Where to Store JWT on Client Side – Security Tradeoffs
Direct Answer
There is no universally safest browser location for a JWT. Avoid long-lived bearer tokens in localStorage or sessionStorage because injected JavaScript can read and export them. An access token kept only in memory has less persistence but active malicious script can still use it. A Secure, HttpOnly cookie prevents JavaScript from reading the credential, but the browser sends it automatically, so the server must use CSRF defenses and a suitable SameSite policy. For many browser apps, a backend-for-frontend that keeps OAuth tokens server-side and exposes only a hardened session cookie gives the browser the least token access.
Common Mistakes & Pitfalls
- Choosing localStorage for convenience: Freshers often pick localStorage because tutorials show it and it's just two lines of code (localStorage.setItem, localStorage.getItem). Interviewers see this as a security red flag. Any XSS vulnerability — even from a third-party script or a comment section — can steal the token. Always articulate why you'd avoid it.
- Not setting SameSite on cookies: Setting a cookie without SameSite leaves it vulnerable to CSRF attacks where a malicious site triggers authenticated requests. Always specify SameSite=Strict or Lax. Strict is more secure (cookie only sent for same-site navigation), Lax allows some cross-site scenarios like following a link.
- Assuming HttpOnly means the cookie can't be sent in requests: HttpOnly means JavaScript can't read the cookie value, but the browser still automatically includes it in HTTP requests to the same domain — that's the whole point. This isn't a vulnerability, it's the intended behavior.
Check your understanding
Answer these without looking back at the article.
- What is an HttpOnly cookie and what does it protect against?
- How does the silent refresh pattern work for SPAs?
- If an attacker can XSS your site, does HttpOnly cookie really protect the token?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.