🧪 Labs › Client-Side
Web Cache Deception & Poisoning
Severity: Medium
Trick the cache into storing the wrong thing — then serve it to everyone.
What it is
A cache sits between users and the app and decides what to store and reuse based on rules (often the URL path or extension). If the app and the cache disagree about what a request means, an attacker can get private responses cached and served to others (deception), or get a malicious response cached under a normal URL (poisoning).
The lever is usually a discrepancy — an unkeyed header the app reflects, or a path the cache treats as static but the app treats as dynamic.
Impact ranges from leaking other users' data to serving attacker content site-wide.
How to approach it
- Learn what the cache keys on and what it ignores, and where the app and cache interpret a request differently.
- For deception, see whether a sensitive page can be requested so the cache stores it as if it were static.
- For poisoning, look for an input that influences the response but isn't part of the cache key.
- Confirm by retrieving the cached artefact as a different user.
Your task
Cause the cache to store a response it shouldn't, and retrieve it as another user.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Make the cache and the app agree on what's cacheable; cache static assets by content, not by path shape.
- Include every response-affecting input in the cache key, or strip it.
- Mark private responses no-store.
More Client-Side labs
- Prototype Pollution — Poison the base object every other object inherits from, and change behaviour everywhere.
- Cross-Site Request Forgery (CSRF) — Make a logged-in victim's browser send a state-changing request they never intended.