no-sensitive-data-in-cache

📡 Live from GitHub — This documentation is fetched directly from no-sensitive-data-in-cache.md and cached for 6 hours.

Keywords: no sensitive data in cache, browser storage, localStorage, security, ESLint rule, CWE-200, information disclosure CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
OWASP Mobile: OWASP Mobile Top 10 M9: Insecure Data Storage

CWE: CWE-200

ESLint Rule: no-sensitive-data-in-cache. This rule is part of eslint-plugin-browser-security.

Quick Summary

Aspect	Details
Severity	High (Information Disclosure)
Auto-Fix	❌ No (requires architectural update)
Category	Security
ESLint MCP	✅ Optimized for ESLint MCP integration
Best For	Apps handling PII or auth tokens
Suggestions	✅ Advice on using session-only storage

Vulnerability: Information disclosure occurs when sensitive data (like passwords, tokens, or PII) is stored in browser-accessible storage like localStorage, sessionStorage, or the Cache API.

Risk: Data in these storages is often persistent and lacks high-fidelity access control. It can be easily accessed by malicious scripts (Cross-Site Scripting - XSS) or anyone with physical access to the device.

Error Message Format

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

🔒 CWE-200 OWASP:M9 | Sensitive Data in Cache detected | HIGH [InfoDisclosure,Privacy]
   Fix: Do not store sensitive data in browser caches; use HttpOnly cookies | https://cwe.mitre.org/data/definitions/200.html

Message Components

Component	Purpose	Example
Risk Standards	Security benchmarks	CWE-200 OWASP:M9
Issue Description	Specific vulnerability	`Sensitive Data in Cache detected`
Severity & Compliance	Impact assessment	`HIGH [InfoDisclosure,Privacy]`
Fix Instruction	Actionable remediation	`Do not store sensitive data in browser caches`
Technical Truth	Official reference	Exposure of Sensitive Info

Rule Details

This rule flags calls to storage methods (set, put, store) where the key name suggests it might contain sensitive information (e.g., keys containing "password", "token", "credit", "ssn").

Why This Matters

Issue	Impact	Solution
🕵️ XSS Impact	Tokens stolen via script	Store tokens in HttpOnly/Secure cookies
🗄️ Persistence	Data stays on public computers	Use session-only variables for sensitive data
🤝 Trust	User data leaked	Encrypt any mandatory client-side storage

Configuration

This rule has no configuration options in the current version.

Examples

❌ Incorrect

// Storing an authentication token in localStorage
localStorage.setItem('user_auth_token', token);

// Storing a password directly
sessionStorage.setItem('temp_password', '123456');

// Using the Cache API to store sensitive data
cache.put('user_profile_data', new Response(JSON.stringify({ ssn: '...' })));

✅ Correct

// Store non-sensitive identifiers instead
localStorage.setItem('user_preferences', JSON.stringify({ theme: 'dark' }));

// For authentication tokens, use HttpOnly cookies (handled on the server)
// Or use short-lived in-memory variables.

// If storage is absolutely necessary, encrypt the data before storing
const encryptedData = encryptSensitiveData(token);
localStorage.setItem('auth_token_encrypted', encryptedData);

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Non-Literal Keys

Why: If the storage key is constructed dynamically or passed as a variable, this rule might miss it as it specifically checks literal strings.

const KEY_NAME = 'auth_token';
localStorage.setItem(KEY_NAME, data); // ❌ NOT DETECTED

Mitigation: Standardize storage keys throughout the application and use a centralized storage wrapper.

Obfuscated Key Names

Why: Developers might use non-obvious key names to store sensitive data.

localStorage.setItem('xyz123', secret_token); // ❌ NOT DETECTED

Mitigation: Perform thorough code reviews and use data masking or encryption.