Web cache poisoning appears when a cache and the application behind it disagree about which parts of a request define a response. The cache stores a response under a key built from selected request components. The application may also use other headers, cookies, query values, or path interpretations when generating that response. If an attacker can influence one of those unkeyed inputs and the resulting response is cached, other users can receive attacker-influenced content without sending the malicious input themselves.
Within network and penetration testing, the important skill is understanding the cache boundary rather than memorizing payloads. PortSwigger’s research methodology starts by identifying a cache oracle, discovering unkeyed input, understanding how that input affects the response, and then determining whether the altered response can be stored under a key shared by victims.
For PenTest+ context, testing must be authorized and controlled. Poisoning a shared production cache can affect real users, so assessment techniques need cache busters, isolated environments, and explicit rules of engagement.
A cache key is an equivalence rule
A cache decides that two requests are equivalent when the fields in its key match. Typical keys include the scheme, host, path, query string, and sometimes selected headers. Inputs excluded from the key can still be forwarded to the origin application. That difference is where poisoning becomes possible.
Suppose an application uses X-Forwarded-Host to construct an absolute script URL, but the edge cache ignores that header when building its key. An attacker can cause the origin to generate a response containing an attacker-controlled host while the cache stores it under the normal page key. Later users can receive the modified response.
API security fundamentals apply here because security depends on how components actually process data, not on what a high-level architecture diagram assumes.
Find a cache oracle before testing influence
A cache oracle is an endpoint where the tester can tell whether a response came from the cache. Headers such as Age, X-Cache, or provider-specific status fields can help, as can timing or controlled dynamic content. Without an oracle, testers can confuse application behavior with caching behavior and reach the wrong conclusion.
Use a unique cache buster during exploration so your experiments do not collide with normal visitor traffic. The buster must itself participate in the cache key. If a query string is unkeyed, for example, a query parameter is a poor cache buster and a keyed header may be safer.
Document cache lifetime and variation behavior. The Vary header, device-specific keys, localization, cookies, and normalization can create multiple cached variants even when the URL looks identical.
Unkeyed inputs matter only when they change a cacheable response
Not every ignored header is a vulnerability. The unkeyed input must influence something meaningful in the origin response, and that response must be cacheable. Test one input at a time and look for reflected values, redirects, generated links, security headers, content selection, or routing changes.
Headers added by proxies are particularly interesting because application frameworks may trust them automatically. Host-related, scheme-related, and rewrite headers can change absolute URLs or routing decisions. Cookies and query parameters can also become dangerous if the cache ignores them while the application does not.
SSRF testing shares a useful mindset: trace how attacker-controlled input crosses trust boundaries and reaches a network-sensitive or security-sensitive operation. Cache poisoning uses a different mechanism, but the analysis of input propagation is similar.
Cache normalization differences create subtle collisions
Some poisoning issues do not rely on obviously unkeyed headers. A cache and origin may normalize paths, ports, delimiters, query parameters, or encodings differently. Two requests that the cache considers the same may be interpreted differently by the application. PortSwigger’s cache-entanglement research shows how these implementation mismatches can create unexpected collisions.
Testing therefore needs to examine parsing and normalization, not just a static list of headers. Compare how the edge, reverse proxy, application server, framework, and application treat the same request. HTTP/2-to-HTTP/1 translation can add another boundary.
These tests can easily become disruptive. Keep them inside the agreed scope and use non-destructive payloads that prove response influence without creating persistent harm.
Impact depends on what the poisoned response can make users do
The cache is a delivery amplifier. The underlying response manipulation determines the impact. A poisoned response might load attacker-controlled JavaScript, redirect users, alter links, weaken security headers, change API metadata, or present incorrect content. If a shared cache serves the response broadly, one malicious request can affect many users.
Scope can also be selective. Cache keys may vary by user agent, language, encoding, or other fields, allowing an attacker to target only a subset of users. That makes monitoring harder because not every request sees the poisoned object.
API authorization testing remains separate: cache poisoning does not automatically bypass authorization. But caching authenticated or user-specific content under an insufficient key can create an authorization-like data exposure, so testers should verify cacheability around personalized responses.
Defenses start by aligning cache behavior with application behavior
The cleanest defense is to ensure that any input capable of changing a cacheable response is either included in the cache key, removed before it reaches the application, or not accepted at all. If a response depends on user-specific or security-sensitive state, it may not be appropriate for shared caching.
Use explicit caching rules rather than relying on file extensions or accidental defaults. Restrict trusted forwarding headers to values set by controlled proxies. Normalize requests consistently across layers. Configure Vary or custom cache-key logic when legitimate response variation depends on a header.
API cache invalidation becomes important during remediation. Fixing the origin is not enough if harmful objects remain cached at edge locations or gateways.
Observability should expose why an object was cached
Security teams need enough telemetry to reconstruct the cache decision: key components, hit or miss status, age, selected origin, and relevant normalization. Application logs alone may show a malicious header once while thousands of later victims receive the cached response without that header ever reaching the origin again.
Monitor unusual cache-key variance, repeated requests that manipulate forwarding headers, unexpected redirects, and changes in cacheability. During an incident, purge affected objects, disable the vulnerable variation, and validate every cache layer because CDNs, reverse proxies, gateways, and application caches can each hold independent state.
Testing should include staging environments configured like production. A vulnerability that exists only because of CDN behavior may disappear in a local development server.
Safe testing proves the mismatch without poisoning real users
Authorized testers should isolate experiments with keyed cache busters, short-lived test routes, or dedicated cache namespaces. Avoid sending exploit payloads to shared pages unless the rules of engagement explicitly permit it. The goal is to demonstrate the equivalence error and response influence, not to create an incident while testing for one.
For CompTIA security study, the deeper lesson is architectural: intermediary systems make security decisions too. A cache is not merely a performance feature. Its key defines which requests are considered equivalent, and that definition must agree with every input the application uses to generate security-relevant content.
Web cache poisoning becomes understandable when viewed as a consistency failure between layers. Find the cache oracle, identify which inputs are keyed, determine which unkeyed inputs affect the response, confirm cacheability safely, and then fix the mismatch at the boundary that created it.
Cache-control headers deserve special attention during review. Directives such as private, no-store, max-age, and s-maxage influence where and how long responses may be stored, but intermediary behavior and application defaults can still differ. Test the deployed stack rather than assuming one header has the same effect at every layer. Authentication status, Set-Cookie behavior, and error responses should also be checked because accidentally caching personalized or failure content can create a broader class of exposure.
Deployment pipelines can reduce regressions by testing cache keys as configuration. When a new header or query parameter begins influencing HTML, redirects, localization, or security behavior, automated tests should verify that the caching layer varies on that input or disables shared caching for the response. That turns cache safety into an architectural invariant rather than a one-time penetration-test finding.
Multi-CDN and multi-region designs add another complication because cache policy may not be identical everywhere. A fix applied to one edge provider or route can leave another path vulnerable. Security validation should enumerate every caching tier that can serve the hostname, verify key behavior in each one, and ensure purge procedures reach all regions. During remediation, inconsistent edge configuration can make a vulnerability appear intermittent rather than resolved.
Security reviews should include error and redirect responses, not only successful pages. Applications sometimes generate redirects from forwarding headers or reflect diagnostic information only when a route fails. If the cache stores those responses, an attacker may be able to poison users even though the normal 200 response is safe. Test representative status codes and content types, and verify that the cache does not unexpectedly normalize them into the same key space. Caching policy is part of application behavior across the full response surface.
After remediation, test the same cache key variations that originally created ambiguity and verify that downstream layers agree on headers, normalization, and routing. A fix is incomplete if one proxy or CDN edge still interprets the request differently from the origin.
