🔐 Auth Token Storage

// Where you store your JWT/access token determines your app's attack surface. Let's explore each option.

localStorage
⚠ HIGH RISK
Persists across sessions. Accessible via document.cookie — and critically, via JS too.
✗XSS attack can steal token instantly with localStorage.getItem('token')
✓Easy to implement
✗No built-in expiry
✗Accessible by ALL JS on the page
sessionStorage
⚡ MEDIUM RISK
Cleared on tab close. Still JS-accessible — same XSS vulnerability.
✗Still vulnerable to XSS
✓Cleared on tab close
✗Not shared across tabs
~Slightly smaller attack window
HttpOnly Cookie
✅ RECOMMENDED
Set by server with HttpOnly + Secure + SameSite flags. JS cannot touch it.
✓XSS cannot steal token (JS blocked)
✓Sent automatically with requests
~Needs CSRF protection
✓SameSite=Strict blocks most CSRF

💥 Attack Scenario Simulator

✅ Best Practice: HttpOnly Cookie Setup

// Server sets cookie after login (Node/Express example):
res.cookie('auth_token', jwtToken, {
  httpOnly: true,    // ← JS cannot access this
  secure: true,     // ← HTTPS only
  sameSite: 'Strict', // ← Blocks cross-site requests (CSRF)
  maxAge: 15 * 60 * 1000 // ← 15 min expiry
});
1
Store access token in memory (React state / module variable), never in localStorage
2
Store refresh token in HttpOnly Secure SameSite=Strict cookie
3
On page load, call /refresh endpoint to silently get a new access token
4
Use short-lived access tokens (15 min) to minimize stolen token damage
Storage XSS Safe? CSRF Safe? Persists? Use For
localStorage✗ No✓ Yes✓ YesNever auth tokens
sessionStorage✗ No✓ Yes✗ NoTemporary UI state only
Memory (JS var)✓ Yes✓ Yes✗ NoAccess tokens (short-lived)
HttpOnly Cookie✓ Yes~ With SameSite✓ YesRefresh tokens (recommended)