Browser Storage Inspector

Inspecting Browser Storage for Security Issues

Web applications store data in localStorage and sessionStorage for performance and user experience — session tokens, user preferences, cached API responses, and feature flags. However, this client-side storage is fully accessible to any JavaScript running on the page, making it a prime target for XSS attacks. If an attacker achieves script injection, they can read every token, password, and API key stored in browser storage. The Browser Storage Inspector analyzes your storage JSON dump to detect sensitive data exposure, expired tokens, oversized values, and storage anti-patterns that create security vulnerabilities.

Paste your browser storage dump (JSON format from DevTools) to receive a security analysis covering authentication token detection, PII exposure, expired JWT tokens, oversized entries, and namespace hygiene. Sensitive values are automatically masked in the output with a show/hide toggle for safe sharing. All processing happens entirely in your browser.

Sensitive Data Detection

The inspector identifies data categories that should not be stored in browser storage:

• Authentication tokens: JWT tokens, session IDs, OAuth access/refresh tokens that enable account takeover if stolen via XSS
• API keys: Service credentials (AWS, Stripe, Firebase) that grant access to backend resources
• Passwords: Plaintext or encoded passwords that users may have saved for convenience
• Personal information: Full names, email addresses, phone numbers, addresses stored without necessity
• Financial data: Credit card numbers, bank account details, or transaction information
• Private keys: Cryptographic private keys or certificates stored in accessible storage

Each detection uses pattern matching against known token formats (JWT structure, AWS key prefixes, typical password field names) and common PII patterns.

Token Expiration Analysis

For detected JWT tokens in storage, the inspector decodes and checks temporal validity:

• Expired tokens: Tokens past their exp claim that should have been cleared — they represent stale data and attack surface without providing any authentication value
• Long-lived tokens: Tokens with expiration months or years in the future — if stored in accessible storage, their long validity window maximizes compromise impact
• Missing expiration: Tokens without exp claims that never expire — infinitely valid tokens stored client-side represent permanent credentials

Storage Hygiene and Best Practices

Beyond security, the inspector identifies storage anti-patterns:

• Oversized values: Individual entries exceeding 100KB that impact page load performance and approach the 5-10MB storage quota limit
• Missing namespacing: Keys without app-specific prefixes that may conflict with third-party scripts sharing the same origin
• Stale data accumulation: Old entries from previous app versions or abandoned features occupying storage space
• Redundant storage: Same data stored in both localStorage and sessionStorage without clear purpose

Best practice is storing only non-sensitive preferences and UI state in browser storage, while authentication tokens belong in httpOnly cookies inaccessible to JavaScript.

Code Examples

Storage Analysis Output

// Input: localStorage dump
{
  "auth_token": "eyJhbGciOiJIUzI1NiIs...",
  "user_email": "alice@company.com",
  "api_key": "sk_live_abcdef123456",
  "theme": "dark",
  "sidebar_collapsed": "true",
  "cart_items": "[{...large JSON...}]"
}

// Inspector findings:
// - CRITICAL: "auth_token" contains JWT token (XSS-accessible)
//   └─ Token expires: 2024-04-15 (30 days — very long for localStorage)
// - HIGH: "api_key" contains Stripe secret key (sk_live_ prefix)
//   └─ Recommendation: Move to server-side, never expose to client
// - MEDIUM: "user_email" contains PII (email address)
// - INFO: "cart_items" is 45KB — consider IndexedDB for large data
// - PASS: "theme" and "sidebar_collapsed" — safe UI preferences
// Security score: 3/10