How do I install the Web Cache Deception skill?

Run npx skillmds@latest add noorqureshi/web-cache-deception in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Web Cache Deception safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Web Cache Deception?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Web Cache Deception free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Web Cache Deception?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Web Cache Deception by noorqureshi — Agent Skill

Name: Web Cache Deception
Author: NoorQureshi

Web Cache Deception

Trick a CDN/cache into storing a victim's authenticated response at a public URL, then read it. Load on "web cache deception", when a CDN/cache sits in front of an app that serves per-user content, or to test whether private pages can be cached. Signals: `X-Cache`/`CF-Cache-Status` headers, caching by file extension, static-looking suffixes on dynamic endpoints.

NoorQureshi 1fe181d 2.5 KB Updated Sep 17, 2026

File contents

Web cache deception

When it applies

A caching layer (CDN, reverse proxy) fronts an app that returns per-user content, and the cache decides what to store by URL pattern/extension. If you can make an authenticated response look cacheable, the cache stores it — and anyone can then fetch that victim's data.

Why it works

The cache and the origin disagree about the URL. The cache sees /account.css and thinks "static, cache it"; the origin ignores the .css suffix (or a delimiter) and serves the dynamic /account page. The victim's private response gets stored under a public key you can request.

Method

Confirm the mismatch: request an authenticated page with a static suffix — /account/foo.css, /account%0a.css, /account;foo.js, /account%2ffoo.css. If the origin still returns the account page (not 404), the origin is ignoring the suffix.
Confirm caching: repeat and watch X-Cache/CF-Cache-Status flip to HIT, or a Age header appear. A cached, authenticated response is the vulnerability.
Prove cross-user impact: as the victim, visit the crafted URL once (or have them); then as an unauthenticated attacker request the same URL and receive the victim's private data.
Explore delimiters/normalisation: caches and origins normalise ;, %2f, //, .., trailing dots differently — Param Miner's rules or manual fuzzing find the pair that splits them.
Report with least data: prove one private field leaked; don't hoard victim data.

Gotchas

This is not cache poisoning: deception caches a victim's real response; poisoning injects a malicious response via unkeyed input. Different bug, different report (web-cache-poisoning).
Needs a genuinely cacheable-looking key and an origin that ignores it — confirm both.
Some CDNs cache by content-type, not extension — test path-based tricks too.

Verify success

An unauthenticated request retrieves another user's authenticated content from the cache (HIT/Age present), reproducibly.

References

Omer Gil "Web Cache Deception"; PortSwigger web cache deception labs; CDN caching-rule docs.

---name: web-cache-deceptiondescription: Trick a CDN/cache into storing a victim's authenticated response at a public URL, then read it. Load on "web cache deception", when a CDN/cache sits in front of an app that serves per-user content, or to test whether private pages can be cached. Signals: `X-Cache`/`CF-Cache-Status` headers, caching by file extension, static-looking suffixes on dynamic endpoints.---# Web cache deception## When it appliesA caching layer (CDN, reverse proxy) fronts an app that returns per-user content, and the cachedecides what to store by URL pattern/extension. If you can make an authenticated response *look*cacheable, the cache stores it — and anyone can then fetch that victim's data.## Why it worksThe cache and the origin disagree about the URL. The cache sees `/account.css` and thinks "static,cache it"; the origin ignores the `.css` suffix (or a delimiter) and serves the dynamic`/account` page. The victim's private response gets stored under a public key you can request.## Method1. **Confirm the mismatch**: request an authenticated page with a static suffix — `/account/foo.css`, `/account%0a.css`, `/account;foo.js`, `/account%2ffoo.css`. If the origin still returns the account page (not 404), the origin is ignoring the suffix.2. **Confirm caching**: repeat and watch `X-Cache`/`CF-Cache-Status` flip to `HIT`, or a `Age` header appear. A cached, authenticated response is the vulnerability.3. **Prove cross-user impact**: as the *victim*, visit the crafted URL once (or have them); then as an unauthenticated attacker request the same URL and receive the victim's private data.4. **Explore delimiters/normalisation**: caches and origins normalise `;`, `%2f`, `//`, `..`, trailing dots differently — Param Miner's rules or manual fuzzing find the pair that splits them.5. **Report with least data**: prove one private field leaked; don't hoard victim data.## Gotchas- This is **not** cache poisoning: deception caches a *victim's* real response; poisoning injects a malicious response via unkeyed input. Different bug, different report (`web-cache-poisoning`).- Needs a genuinely cacheable-looking key *and* an origin that ignores it — confirm both.- Some CDNs cache by content-type, not extension — test path-based tricks too.## Verify successAn unauthenticated request retrieves another user's authenticated content from the cache(`HIT`/`Age` present), reproducibly.## ReferencesOmer Gil "Web Cache Deception"; PortSwigger web cache deception labs; CDN caching-rule docs.

Frequently asked questions