Exploiting a Flaw in How Servers and Caches Talk to Each Other
Welcome to Day 29 of our bug bounty exploration! Today’s vulnerability is one of the most elegant and subtle ones I’ve ever encountered. It doesn’t require bypassing authentication or injecting code. Instead, it exploits the misunderstood relationship between a server and its caching layer (like Varnish or Nginx). The target was a financial dashboard app. By simply adding .css to the end of a private URL, I tricked the system into saving a user's sensitive financial data in a public cache. Minutes later, I was able to retrieve that data, fully rendered, without needing to log in. This Web Cache Deception (WCD) attack earned a $4000 bounty.
The Core Concept: How Caching Works (and Fails)
A reverse proxy cache (e.g., Varnish, Nginx, Cloudflare) sits in front of a web application. Its job is to save (cache) responses to certain requests to improve performance. It usually decides what to cache based on:
- The file extension in the URL (e.g.,
.css,.js,.png). - The
Cache-Controlheaders sent by the application…