When an API Key Lives in Local Storage: A Subtle but Risky Pattern

While testing a production web application, I noticed a third-party API key (used for consent and privacy management) stored directly in the browser’s localStorage. It’s a common pattern in modern frontends—but one that can quietly expand your attack surface.

This post breaks down why it matters, how it can be abused in real scenarios, and what both developers and bug hunters should look for.

What Happened

• A consent-management service API key was present in localStorage on page load (no authentication required).


• Any JavaScript executing in the page context could read it.


• The key appeared to be used for client-side interactions with a third-party API.

Why This Is Risky

1) Local Storage Is Not a Secret Store

Anything in localStorage is:

• Readable by any script on the page


• Persisted across sessions


• Exposed to browser extensions and injected scripts

If an attacker lands an XSS—even a low-impact one—they can exfiltrate the key instantly.

2) Keys Enable Backend Interaction

Even if the key is “just for a third-party service,” it may:

• Call APIs that mutate state (e.g., consent records)


• Access user-related data


• Trigger workflows like DSAR operations

3) Low Impact Alone, Higher Impact When Chained

On its own, a single exposed key might look benign. Combined with:

• XSS


• Misconfigured CORS


• Over-permissive API scopes

…it can become a practical exploitation path.

Threat Modeling the Scenario

Attacker prerequisites:

• Ability to run JavaScript in the victim’s browser (XSS, malicious extension, supply-chain script)

What they can do:

• Read localStorage → extract API key


• Replay requests to the third-party API


• Attempt to manipulate consent or privacy data (depending on API permissions)

Potential outcomes:

• Unauthorized modification of user preferences


• Abuse of consent APIs


• Compliance and trust issues

How to Verify (For Bug Hunters)

1. Open the target site.


2. Open DevTools → Application tab → Local Storage.


3. Look for keys like:

• 
  

  apiKey, token, auth, clientKey

  
  
  
  
  
  1. Trace usage:
  
  
  
  



• Search in Sources/Network for where the key is used.



• 
  

  Inspect requests made with the key.

  
  
  
  
  
  1. Validate impact:
  
  
  
  



• Are there write operations?




• Can you call endpoints outside the app?




• Are scopes restricted?

Tip: Don’t stop at “key found.” Always try to demonstrate:

• What the key can do


• Whether it can be abused outside the browser context

Developer Guidance

1) Don’t Store Secrets in the Browser

• Treat API keys like credentials.


• If it must be used client-side, assume it is public.

2) Use a Backend Proxy

• Keep sensitive keys server-side.


• Let the frontend call your backend, which then calls the third-party API.

3) Scope and Restrict Keys

• Limit permissions to the minimum required.


• Bind keys to specific domains/IPs if supported.


• Separate read vs write capabilities.

4) Rotate and Monitor

• Rotate exposed keys immediately.


• Monitor usage patterns for anomalies.

5) Harden the Client

• Implement a strict Content Security Policy (CSP).


• Reduce third-party script exposure.


• Sanitize and validate all inputs to minimize XSS risk.