Safeguard
Application Security•

CWE-524 Cache Containing Sensitive Information: How to Prevent It

Caches speed things up, but a cache that outsiders can read leaks whatever it holds. What CWE-524 means, a real CVE pattern, and the three fixes.

Safeguard Security Team
2 min read

CWE-524 is code that uses a cache holding sensitive information, where that cache can be read by an actor outside the intended control sphere. It is not tied to a language.

How it happens

Applications use caches to cut the cost of talking to remote systems or doing heavy work. MITRE notes a cache can hold pools of objects, threads, connections, pages, financial data, passwords and other resources. If unauthorized actors can reach the cache, they can read what is in it.

Common routes: a shared cache with no access control, a cache key that does not include the user, a cache file written to a readable directory, and HTTP responses cached by a shared proxy or by the browser.

The HTTP version appears in the record. CVE-2024-30127 is listed as a product that does not set the no-cache option in the HTTP Cache-Control header, allowing sensitive information to be cached.

# Risky: per-user data cached under a shared key
cache.set("dashboard", render_dashboard(user))
page = cache.get("dashboard")          # next caller gets someone else's page

# Better: scope the key to the user
cache.set(f"dashboard:{user.id}", render_dashboard(user))

What an attacker gains

MITRE lists reading application data. Whatever the cache holds, such as tokens, personal data or account details, becomes available to the reader.

How to find it

Static analysis can find some instances by following sensitive data into caches. Also check by hand:

  • List each cache and what goes into it.
  • Check who can read it, whether by network, file permission or shared process.
  • For web responses, look at the Cache-Control headers on pages that show account data.

How to fix it

MITRE lists three design steps.

  1. Protect information stored in the cache.
  2. Do not store unnecessarily sensitive information in the cache.
  3. Consider using encryption in the cache.

Practical notes: key caches by user or tenant, set short lifetimes, restrict the cache service to the application's network, and never place secrets in a cache just for convenience.

Quick check

What is the cheapest control against sensitive cache exposure?

Do not put sensitive data in the cache in the first place.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.