Cache Poisoning Tester

Understanding Web Cache Poisoning, OWASP Risk, and Cross-User Defacement

Web cache poisoning sits in an uncomfortable blind spot for many teams. A request looks completely ordinary, the response code is a clean 200, and nothing in a standard monitoring dashboard lights up red — yet a single crafted request can quietly corrupt what an entire cache layer serves to every subsequent visitor. The core issue is almost always the same: a header, cookie, or query parameter that the origin server reads and uses to build a response, but that the cache in front of it never includes in its cache key. OWASP catalogs this pattern because the consequences scale so quickly. One attacker request becomes the version of the page everyone else receives, until the cache entry expires or is purged.

The most common entry point is the family of forwarding headers — X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL, and similar variants — that reverse proxies and load balancers add for legitimate routing purposes. When an application trusts one of these values to build a canonical link, a redirect target, or an asset URL, and a caching layer in front of it treats the response as cacheable without factoring that header into its key, an attacker can submit one request with a malicious host value and have the poisoned output served to thousands of real users who never sent that header themselves. This is sometimes called cross-user defacement, since the visible symptom is often broken links, injected scripts, or unexpected redirects appearing for visitors who did nothing wrong.

HTTP response splitting is a closely related but distinct vulnerability worth testing for in the same pass. It occurs when unsanitized input reaches a point where it can inject carriage-return/line-feed sequences into the raw HTTP response, effectively allowing an attacker to forge additional headers or even a second response body. Combined with an upstream cache, response splitting can be used to smuggle a fabricated response into the cache itself, compounding the impact far beyond a single request. Because the underlying flaw usually lives in how an application or proxy assembles headers from untrusted input, it tends to surface in older middleware, custom routing logic, or any code path that concatenates header values directly into output.

Testing for these issues responsibly starts with understanding what your cache actually keys on. Tools like this one send a baseline request to fingerprint cache-indicating headers — Cache-Control, Age, X-Cache, CF-Cache-Status, Vary, and similar signals — and then resend the request with a uniquely marked value in each commonly unkeyed header. If that marker shows up reflected back in the body or headers of a response that also shows caching indicators, you have a strong signal that the header is both trusted by the origin and excluded from the cache key, the exact combination that enables poisoning. A parallel check sends a CRLF-style payload through a query parameter to see whether it gets reflected as a forged header, which points toward response-splitting risk.

None of this replaces a full security review, manual testing by an experienced assessor, or a proper threat model for high-value applications. What automated testing like this is good for is catching the low-hanging, high-impact misconfigurations early and often — ideally as part of a regular cycle alongside your other vulnerability checks, rather than a one-time audit. Cache configurations drift as infrastructure changes, CDNs get added, and new headers get introduced by load balancers, so a finding that was clean six months ago is not a guarantee today. Treat a passing grade as a snapshot, not a certificate, and always test only domains you own or are explicitly authorized to assess.