Web cache deception
Web cache deception is path confusion that stores a private response at a URL the cache thinks is static. It is not cache poisoning: poisoning is unkeyed input that changes what other users receive.
Skill: Cache deception and cache poisoning
Ask: Is a private response stored at a URL the cache treats as static, or does an unkeyed input change what other users receive?
Stop: You can say which of the two bugs you observed. Do not file one as the other.
Practice the class in the browser: PortSwigger Web Security Academy. The lab is theirs. This page is the stop condition and the disclosures.
Checklists
- Cache deception - Deception is a disagreement about what is safe to store. A second client must receive the private response before you call it cached.
Disclosures
No public card yet.
Playbooks
- Web cache deception - Cache deception stores a private response at a URL the cache thinks is static. It is not cache poisoning. Poisoning changes what other users receive. Deception discloses your own authenticated page to a second client that never logged in.
Tools
- Burp Suite - The industry-standard intercepting proxy for manual web testing. Community edition is free; Pro adds the active scanner and automation.
Questions
How is cache-deception different from cache poisoning?
Deception stores a private response at a URL the cache treats as static. Poisoning uses unkeyed input to change the response other users receive. Do not mix the reports.
How do I prove it without a real user?
Two clients you control. One is authenticated and requests the confusing path. The other has no credentials and must receive the cached private body. Do not leave someone else's data in the cache.
This page is the linked pack hunt_brief("cache-deception") returns on the MCP connector. Authorized testing only.