Category: Attack Techniques

Web Cache Deception

Also known as: WCD, Web Cache Deception Attack

Simply put

Web Cache Deception is an attack where an attacker tricks a web cache into storing sensitive content that should only be delivered dynamically to individual users. Once cached, that private content may then be served to other users who request the same URL. The attack exploits differences in how the web server and the caching layer interpret the same URL.

Formal definition

Web Cache Deception is a vulnerability class in which an attacker exploits URL parsing discrepancies between a web application server and its caching layer to cause the cache to incorrectly store dynamic, user-specific, or otherwise sensitive responses as if they were static cacheable resources. The attack typically involves crafting a URL that the origin server interprets as a request for authenticated or personalized dynamic content, while the cache layer treats the request as a static resource eligible for storage based on path suffix, file extension, or cache rule heuristics. Once the response is cached, the attacker retrieves it directly from the cache without authentication, potentially exposing session data, account details, or other sensitive information. The root cause is inconsistency in URL normalization, path segment handling, or cache key construction between the origin and the caching component.

Why it matters

Web Cache Deception is significant because it can expose sensitive, authenticated user data to unauthenticated attackers without requiring any direct interaction with the victim's session. When a caching layer is tricked into storing a response that contains personal account details, session tokens, or other private information, that data becomes retrievable by anyone who requests the same crafted URL. The attack is particularly dangerous because the vulnerability exists at the infrastructure level, meaning a single misconfiguration can affect large numbers of users simultaneously.

The attack was publicly presented at Black Hat USA 2017 by researcher Omer Gil, which brought widespread attention to how caching infrastructure, intended to improve performance and scalability, can inadvertently become an attack surface. The technique is relevant to any application that uses a caching layer in front of a web server, including those relying on CDNs, reverse proxies, or application-level caches, which describes a broad portion of modern web deployments.

Beyond data exposure, Web Cache Deception is difficult to detect through standard monitoring because the attacker's HTTP request may appear superficially similar to legitimate traffic. The cached response is served by the cache itself rather than by the origin application, which means application-layer logging may not capture the moment of data exfiltration. This makes post-incident forensics more complex and underscores the importance of preventive controls over reactive detection.

Who it's relevant to

Application Security Engineers

Application security engineers need to understand Web Cache Deception because it arises from the interaction between application routing logic and caching infrastructure, making it easy to overlook during standard code review. Assessing risk requires evaluating how the origin server handles unexpected URL suffixes alongside how the caching layer applies its cache rules, which demands familiarity with both layers of the stack.

DevOps and Platform Engineers

Engineers responsible for configuring CDNs, reverse proxies, and caching layers are directly accountable for the cache rules and path-matching policies that enable or prevent Web Cache Deception. Misconfigurations in cache key definitions, cache eligibility rules based on file extensions, or path normalization settings can introduce this vulnerability even when the application code itself is correct.

Penetration Testers and Bug Bounty Researchers

Web Cache Deception is a commonly tested vulnerability class in web application penetration testing and bug bounty programs. Testers typically probe for it by appending static-looking path segments or extensions to authenticated endpoints and observing whether the caching layer stores the resulting response. Understanding the variation in attack mechanics across different server and CDN configurations is important for thorough coverage.

Security Architects

Architects designing systems that place caching infrastructure in front of authenticated web applications must account for Web Cache Deception when defining cache policies. Decisions about URL normalization, cache key scope, and which response types are eligible for caching have direct security implications and should be addressed explicitly in architecture and threat modeling documentation.

Compliance and Risk Professionals

Web Cache Deception can result in the unauthorized disclosure of personal data or account information, which may carry regulatory implications under frameworks that require protection of sensitive user data. Risk assessments for applications using CDNs or caching proxies should include this vulnerability class as part of evaluating data exposure risk.

Inside WCD

Cache Key

The identifier a caching layer uses to store and retrieve responses, typically composed of elements such as the URL path and host. In web cache deception, attackers manipulate the components of the cache key to cause a private response to be stored and later served to other users.

Cache Rules

Configurations that determine which responses a cache will store, often based on file extensions, path patterns, or content types. Overly broad or extension-based cache rules are a primary enabler of web cache deception attacks.

Path Confusion

The condition that makes web cache deception possible, where the origin server and the caching layer interpret a URL path differently. The cache may treat a URL as pointing to a static resource while the origin server serves dynamic, user-specific content.

Static Resource Suffix or Extension

File extensions such as .css, .js, or .png that attackers append to a URL to trick cache rules into treating the response as cacheable. The cache stores the private response because the URL superficially resembles a static asset request.

Victim-Authenticated Response

The sensitive HTTP response generated by the origin server for an authenticated user, which the attacker causes to be cached. Subsequent requests to the same cache key by the attacker retrieve this stored private content without authentication.

Cache-Control and Vary Headers

HTTP response headers that instruct caches on storage and differentiation behavior. Properly configured headers such as Cache-Control: no-store or a Vary header on the Cookie or Authorization field can prevent sensitive responses from being cached and shared across users.

Delimiter Handling Discrepancy

Differences in how path delimiters, encoded characters, or path normalization are processed by the origin server versus the caching layer. Attackers exploit these discrepancies to craft URLs that the cache and origin each interpret in conflicting ways.

Common questions

Answers to the questions practitioners most commonly ask about WCD.

Does Web Cache Deception only affect public CDN caches, or can internal caches be vulnerable too?

Web Cache Deception can affect any caching layer that sits between users and the origin server, including reverse proxies, load balancers with caching capabilities, and application-level caches deployed internally. The attack is not limited to public CDN infrastructure. Any cache that makes storage decisions based on URL patterns or file extensions without properly validating the response's intended cacheability may be exploitable, regardless of whether it is publicly operated or privately managed.

Is Web Cache Deception the same as cache poisoning?

No. These are distinct attacks with different mechanisms and objectives. In cache poisoning, an attacker manipulates what gets stored in the cache so that other users receive malicious content when requesting legitimate URLs. In Web Cache Deception, the attacker tricks the cache into storing a victim's private response, which the attacker then retrieves. Cache poisoning targets the integrity of cached responses delivered to others, while Web Cache Deception targets the confidentiality of a specific user's sensitive data.

How can developers configure cache rules to prevent Web Cache Deception?

Developers and infrastructure teams should ensure that caching rules are based on explicit allowlists of cacheable endpoints rather than relying on file extension matching or URL suffix patterns. Cache storage should be conditional on the presence of appropriate response headers such as Cache-Control directives set by the origin. Responses containing session-specific or authenticated content should include headers like Cache-Control: no-store or private to signal that the content must not be cached, and the caching layer must be configured to honor these headers.

What Cache-Control headers should an application set to reduce exposure to this attack?

Applications serving authenticated or user-specific content should set Cache-Control: no-store on those responses to instruct caches not to retain the response under any circumstances. Using Cache-Control: private indicates that the response is intended for a single user and should not be stored by shared caches. Teams should audit all endpoints that return personalized data to confirm these headers are consistently applied, since a single misconfigured endpoint may be sufficient for exploitation.

How should security testers assess whether an application is vulnerable to Web Cache Deception?

Testers typically craft requests by appending path segments with cacheable-looking extensions, such as .css or .js, to URLs that serve authenticated content, for example by requesting a profile page as /account/profile/test.css. They then observe whether the response is cached and retrievable without authentication. Testing should cover authenticated endpoints that return sensitive data, and testers should verify both that the cache stores the response and that it is subsequently served to unauthenticated or differently authenticated requests. This testing requires an active session and cannot be performed through static analysis alone.

Are web application firewalls effective at blocking Web Cache Deception attacks?

Web application firewalls may provide some defense by detecting and blocking requests that contain anomalous path segments appended to known application routes, but this approach is generally not reliable as a primary control. WAF rules for this attack pattern are typically signature-based and may miss novel path variations or applications with complex URL structures. The more robust mitigations are correct Cache-Control header configuration at the application layer and cache rule hygiene at the infrastructure layer. WAF controls may serve as a supplementary layer but should not be treated as sufficient on their own.

Common misconceptions

Web cache deception is the same as cache poisoning.

The two attacks are distinct. In web cache deception, the attacker tricks the cache into storing a legitimate but private response belonging to a victim, then retrieves it. In cache poisoning, the attacker causes the cache to store a malicious response that is then served to other users. The direction and goal of manipulation differ between the two techniques.

Using HTTPS protects against web cache deception.

Transport encryption does not prevent web cache deception. The attack operates at the application and caching layer, not the transport layer. A response served over HTTPS can still be incorrectly cached and exposed if cache rules and response headers are misconfigured.

Only publicly accessible or CDN-based caches are at risk.

Web cache deception can affect any caching layer that sits between the origin server and the client, including reverse proxies and in-infrastructure caches, provided path interpretation discrepancies and permissive cache rules exist. The attack is not limited to large CDN deployments.

Best practices

Set explicit Cache-Control: no-store or Cache-Control: private headers on all responses that contain user-specific or sensitive content, so that caching layers are instructed not to store those responses regardless of URL structure.

Configure cache rules based on verified content type from the origin response rather than solely on URL path patterns or file extensions, which can be manipulated by an attacker.

Audit and restrict delimiter and path normalization behavior so that the origin server and caching layer interpret URL paths consistently, reducing the opportunity for path confusion discrepancies that enable the attack.

Include the Cookie or Authorization header in the Vary header for any response that is session-dependent, so that the cache treats requests from different users as distinct entries rather than serving a cached private response to unauthorized requesters.

Regularly test caching behavior by reviewing how the caching layer responds to URLs with appended static-resource suffixes or encoded path segments, verifying that sensitive responses are not stored and are not retrievable without valid authentication.

Apply the principle of least privilege to cache configurations by defaulting to non-caching behavior and explicitly allowlisting only those URL patterns and content types that are confirmed to be non-sensitive and safe to cache.