Session token stored in localStorage

What it is

`localStorage` is readable by any JavaScript executing on the page. A single XSS — even a transient one — exfiltrates everything in storage to the attacker. The defense is to keep auth tokens in HttpOnly cookies (which JS cannot read) or in memory only (cleared on reload).

Why it matters for MCP

MCP servers often ship with their own admin UIs or web dashboards that use a JWT for auth. Putting that JWT in `localStorage` is the path of least resistance for SPA development, but it's the most common vector by which an MCP server's admin gets popped via an unrelated XSS in a dependency.

Vulnerable example

async function login(creds) {

  const res = await fetch("/api/login", { method: "POST", body: JSON.stringify(creds) });

  const { token } = await res.json();

  localStorage.setItem("auth_token", token);

}

Secure example

// Server sets HttpOnly cookie; JS never sees the token.

async function login(creds) {

  const res = await fetch("/api/login", {

    method: "POST",

    body: JSON.stringify(creds),

    credentials: "include",

  });

  if (!res.ok) throw new Error("login failed");

  // No client-side token storage.

}

How MCPSafe detects this

MCPSafe flags `localStorage.setItem(...)` / `sessionStorage.setItem(...)` calls where the key contains `token`, `jwt`, `auth`, `session`, or `bearer` (case-insensitive). Server-side cookie sets are not flagged.

See the full threat catalog for every documented detection.

Further reading

• CWE-522: Insufficiently Protected Credentials
• OWASP: HTML5 Security Cheat Sheet