iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Web cache poisoning happens when an input changes a website’s response but is missing from the cache key. The cache can then store that altered response under a key also used by ordinary requests, potentially serving it to later visitors. It requires three things: a response-changing input the cache does not key on, a response that can be cached, and requests that share the affected cache key.
How can a cached response become a security problem?
A web cache stores responses so it can serve them again without asking the origin server—the application or server that generates the response—for each request. To decide whether a stored response matches a new request, the cache uses a cache key: a selection of request properties, such as the URL and possibly certain headers. Requests with the same key may receive the same stored response.
An unkeyed input is a request component that the cache does not include in that key. If the origin nevertheless uses that component to change its response, the origin and cache treat the requests as different and equivalent, respectively. When the changed response is cacheable, the cache may save it for later requests with the same key.
For example, imagine an application that uses a forwarding header supplied with a request to build an absolute link in its HTML, while the CDN does not include that header in its cache key. A crafted header value could alter the generated page. If the CDN stores that version under the same key as a clean request, another visitor whose request matches that key could receive the changed page. This is a hypothetical illustration; whether it works depends on the application and cache configuration.
#1 Best Overall
Cloudflare defines the attack this way: “A cache poisoning attack uses an HTTP request to trick an origin web server into responding with a harmful resource that has the same cache key as a clean request.” Cloudflare’s cache-poisoning documentation was last updated May 6, 2026.
What can an attacker accomplish?
The consequences depend on what the altered response contains and which users share the affected cache entry. Possible outcomes include cross-site scripting, redirects, or page substitution. A shared cache can distribute a poisoned response to more than the person who sent the original request, but a finding does not automatically affect every visitor.
Rank #2
Reach and duration depend on the cache layer and key involved, whether the response is eligible for caching, how long it remains stored, and whether additional dimensions—such as the response’s Vary behavior—separate requests into different entries. A CDN, a reverse proxy, and an application-level cache may each behave differently, so the end-to-end path matters.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →How is cache poisoning different from cache deception?
Both issues involve a mismatch between cache behavior and origin behavior, but the mechanism differs:
- Cache poisoning: an unkeyed request input changes an origin response, and the changed response is stored under a key shared with clean requests.
- Web cache deception: an attacker tricks a cache into storing private or personalized content under a URL the cache treats as static-looking or otherwise cacheable.
For background on the distinction, see PortSwigger’s web cache poisoning guide and its web cache deception guide.
How can defenders test for it safely?
The central question is whether a request input changes a response without changing the cache key. PortSwigger describes a workflow of finding candidate unkeyed inputs, checking what response change they produce, and determining whether the resulting response can be cached. Its practical web cache poisoning research discusses Param Miner, an open-source Burp Suite extension, as a way to identify candidate inputs. A cache-busting value can also help distinguish a fresh origin response from an existing cached one.
Rank #4
- Get authorization. Test only systems you are permitted to assess. A harmful test against a shared live cache could affect other visitors.
- Use a controlled environment or coordinate with the system owner. Agree on a safe test window, cache-busting approach, and cleanup plan before sending inputs that might alter a cacheable response.
- Trace the full request path. Confirm how the CDN, any proxy, and the origin handle the input and cache key; behavior at one layer may not describe the whole system.
- Verify storage and sharing, not just response variation. Establish whether the altered response is actually cached and whether a clean request with the same key receives it.
- Clean up and recheck. Remove test entries where possible and verify that later clean requests receive the intended response.
These steps reflect the testing principles in PortSwigger’s guidance; avoid placing a harmful payload into a shared production cache just to demonstrate impact.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallHow should teams prevent or respond to poisoning?
There is no single cache-key setting that fits every application. Teams need to decide whether each response-changing input should be rejected, represented in the key, or handled on a route that is not shared-cacheable. The right choice also depends on whether the route needs shared caching, how consistently layers parse requests, and the effect of response variation on cache hits.
- Align response behavior with the key. Every input that can change a cacheable response should either be represented in the cache key or rejected for that route.
- Share only intended responses. Do not let unkeyed headers or a GET request body change a response that a shared cache may store.
- Handle forwarding headers as trusted data only when appropriate. Configure trusted proxies to set or replace these headers, and canonicalize host and scheme before using them to build links or redirects.
- Keep parsing consistent across layers. CDN, proxy, and origin should agree on URL normalization, query handling, and routing. Reject ambiguous inputs rather than letting different layers interpret them differently.
- Set explicit policy for sensitive responses. Avoid shared caching when authorization or personalization affects the representation. OWASP cautions that
Vary: Cookieshould not be treated as a general authorization boundary; see its Cache Control Cheat Sheet. - After an incident, fix behavior as well as stored entries. Purge affected cache layers, correct the response/key mismatch, then verify the full request path before restoring caching. Purging alone does not remove the underlying flaw.
For broader implementation guidance, consult Cloudflare’s cache-poisoning documentation and the OWASP Cache Control Cheat Sheet.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
