web-cache-deception

Tests CDN and proxy caching layers for cache deception and cache poisoning vulnerabilities.

Updated Jun 5, 2026
One-click install
npx skills add https://github.com/lNwNl/Praxis --skill web-cache-deception-lnwnl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-cache-deception
Source: https://github.com/lNwNl/Praxis/tree/main/skills/_disabled/web-cache-deception
Command: npx skills add https://github.com/lNwNl/Praxis --skill web-cache-deception-lnwnl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web applications behind CDNs and reverse proxies can leak authenticated user data or serve attacker-controlled content when cache keys and path normalization differ between layers. This Skill provides a structured methodology to identify, exploit, and verify web cache deception and cache poisoning vulnerabilities during authorized security assessments. ## Core Features & Use Cases - Cache Deception Testing: Append static extensions (.css, .js, .png) to authenticated endpoints, exploit path normalization differences between CDN and origin, and verify cross-user cache hits to steal victim session data. - Cache Poisoning Techniques: Discover and exploit unkeyed headers (X-Forwarded-Host, X-Original-URL), unkeyed parameters (utm_*, callback), Fat GET bodies, and parameter cloaking via semicolon or duplicate-parameter parsing differentials. - CDN-Specific Behavior Reference: Covers cache key composition, debug headers, and quirks for Cloudflare, CloudFront, Akamai, Varnish, and Fastly, plus Vary header manipulation and ESI injection. - Use Case: During a web penetration test, you notice an X-Cache header on responses. Use this Skill to determine the cache key composition, test whether /account/profile/x.css returns cached authenticated content, and check if X-Forwarded-Host is reflected but unkeyed. ## Quick Start Test whether the target's CDN caches authenticated responses by appending a static extension like .css to the /account/profile endpoint and checking for an X-Cache HIT on an unauthenticated follow-up request.

Frequently Asked Questions about web-cache-deception

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for web cache deception vulnerabilities?▼

Append a static file extension like .css or .js to an authenticated endpoint such as /account/profile/x.css, then request the same URL without credentials. If the second request returns X-Cache: HIT with the victim's authenticated content, the application is vulnerable.

What is the difference between cache poisoning and cache deception?▼

Cache deception tricks a victim into visiting a crafted URL so their authenticated response gets cached and later read by the attacker. Cache poisoning actively injects malicious content into the cache via unkeyed inputs like X-Forwarded-Host, affecting all users who hit that cache entry.

Which HTTP headers are commonly unkeyed in CDN caches?▼

Commonly unkeyed headers include X-Forwarded-Host, X-Forwarded-Scheme, X-Forwarded-Proto, X-Original-URL, X-Rewrite-URL, and True-Client-IP. If any of these are reflected in the response but excluded from the cache key, the cache can be poisoned.

How do Cloudflare and CloudFront differ in default cache keys?▼

Cloudflare includes the query string in its default cache key and caches by file extension, while CloudFront excludes query strings and cookies from the key unless explicitly configured. These differences change which parameters are viable poisoning vectors on each platform.

Why does cache deception fail on some authenticated endpoints?▼

Endpoints that send Cache-Control: no-store or private, or include Vary: Cookie, prevent shared caching of authenticated responses. Applications that strictly route paths and reject unknown trailing segments also block the path confusion the attack relies on.