Cache Poisoning

Also Known As

TL;DR

Explanation

Web cache poisoning abuses the gap between what a caching layer uses as a cache key (typically URL + Host) and what the backend actually processes (including unkeyed headers like X-Forwarded-Host). By injecting a malicious value into an unkeyed header that the application reflects in its response, an attacker can poison the cached copy served to all subsequent visitors. Mitigations include keying caches on all relevant headers, disabling reflection of arbitrary headers, and using Vary headers appropriately.

How It's Exploited

Common Misconception

Why It Matters

Common Mistakes

• Reflecting unkeyed request headers (like X-Forwarded-Host or X-Original-URL) into cached responses.
• Including user-controlled query parameters in responses that are served from cache to other users.
• Not separating cached static resources from dynamic personalised responses.
• Trusting the Host header for generating absolute URLs in cached pages.

Code Examples

// Caching a response that includes unvalidated Host header
\$cacheKey = 'page:' . \$_SERVER['HTTP_HOST'] . \$_SERVER['REQUEST_URI'];
\$cached   = \$cache->get(\$cacheKey);
if (!\$cached) {
    \$html = render(['canonical' => 'https://' . \$_SERVER['HTTP_HOST'] . '/page']);
    \$cache->set(\$cacheKey, \$html);
}

// Use a fixed canonical hostname — never trust the Host header for cache keys
\$canonicalHost = config('app.url'); // 'https://yourapp.com'
\$cacheKey      = 'page:' . md5(\$canonicalHost . \$_SERVER['REQUEST_URI']);

// In nginx — only forward known Host values to PHP:
// if (\$host !~* ^(yourapp\.com|www\.yourapp\.com)\$) { return 444; }

References

• ↗ https://portswigger.net/web-security/web-cache-poisoning
• ↗ https://owasp.org/www-community/attacks/Cache_Poisoning

Tags

Related Terms