Cache Poisoning Prevention: Securing Your Node.js and PHP Apps

During an on-call rotation last year, I spent about six hours chasing a ghost bug where users were occasionally seeing someone else’s account dashboard. We initially suspected a database session leak, but the root cause was much quieter: we were generating cache keys based on unvalidated request headers, leading to a classic case of cache poisoning.

When your application relies on intermediary caches (like Varnish, Cloudflare, or Nginx) to boost web performance, the cache key acts as the unique identifier for a piece of content. If an attacker can influence the inputs that go into that key, they can trick your server into serving private data to the wrong user.

Understanding Cache Key Vulnerabilities

Most developers assume that the cache key is just the request URL. In reality, modern applications often include headers like X-Forwarded-Host, Accept-Language, or custom versioning headers to serve varied content. The problem occurs when your application trusts these headers implicitly without normalization.

If you don't control the cache key strictly, you expose your users to a significant data leak. An attacker can send a request with a crafted header that matches a valid, cached response intended for someone else, or worse, poison the cache with malicious content that gets served to every subsequent user.

We’ve previously discussed how to handle Cache-Control Header Security: Preventing Sensitive Data Exposure, but controlling the header isn't enough if the cache key itself is predictable or manipulatable.

Identifying the Risk in Node.js and PHP

In Node.js, we often use middleware or reverse proxies to handle caching. If you use a library like express-cache-middleware, you might be tempted to pass the entire req.headers object into the key generator. Don't do that.

JAVASCRIPT
// DON'T DO THIS: Trusting all headers for cache keys
const cacheKey = JSON.stringify(req.headers) + req.url;

In PHP, the same risk exists when using frameworks that integrate with Redis for page caching. If you pull data directly from $_SERVER variables to build a cache hash, you’re creating an entry point for application security failures.

The Anatomy of a Poisoned Key

If you haven't already, I highly recommend reading up on Cache Poisoning Prevention: Securing Against X-Forwarded-Host Manipulation to understand how header spoofing interacts with your infrastructure.

Mitigating Cache Poisoning

To stop cache poisoning before it happens, you must treat your cache key construction as a strict whitelist operation.

1. Explicit Whitelisting: Instead of grabbing all headers, explicitly extract only the headers you need for cache variation (e.g., Accept-Language).
2. Normalization: Always lowercase and trim headers before they enter the hash function.
3. Session Isolation: Ensure that any content containing PII (Personally Identifiable Information) is never stored in a shared cache. If it must be cached, ensure the cache key includes a non-guessable, user-specific salt or is handled by a private browser cache.

Here is a safer approach for generating a cache key in Node.js:

JAVASCRIPT
// DO THIS: Whitelist only safe headers
const getCacheKey = (req) => {
  const allowedHeaders = [CE9178">'accept-language'];
  const headerPart = allowedHeaders
    .map(h => CE9178">`${h}=${req.headers[h] || 'default'}`)
    .join(CE9178">'|');
  
  return crypto.createHash(CE9178">'sha256')
    .update(req.url + headerPart)
    .digest(CE9178">'hex');
};

When Things Go Wrong

We once tried to fix a performance bottleneck by caching API responses based on the Referer header. It was a mistake. Attackers started spoofing the Referer to bypass our rate limits and eventually poisoned our cache with 403 Forbidden responses, effectively taking down our public-facing API for roughly 45 minutes until we purged the cache and reverted the change.

Always verify your cache configuration in a staging environment that mirrors your production proxy settings. If you’re seeing unexpected behavior, check your proxy logs for high cache-miss rates or unusual header combinations.

Final Thoughts

Securing your application is a continuous process. While I've focused on cache keys here, remember that these vulnerabilities often overlap with broader issues like Preventing Host Header Injection in Node.js and PHP Apps.

I'm still refining our internal approach to cache purging—automated purges are great, but they can be abused if the purge endpoint itself isn't secured. Start by auditing your current cache key generation logic today; the peace of mind is worth the effort.

FAQ

Q: Should I ever cache responses with Authorization headers? A: Generally, no. If you must, ensure the cache is private (Cache-Control: private) and never stored on a shared CDN or intermediary proxy.

Q: Is it safe to include the User-Agent in the cache key? A: It's risky. User-Agent strings are easily spoofed and can lead to cache fragmentation, where your cache fills up with thousands of unique keys for the same content.

Q: How do I know if I've been poisoned? A: Monitor your cache hit ratio and watch for anomalies in your access logs where a single IP is requesting the same URL with hundreds of different header variations.