What Is Web Cache Poisoning? What You Need to Know

Web caches are built to accelerate content delivery, but they can be turned into powerful weapons against your users. An attacker can exploit subtle flaws in how a cache identifies and stores information, tricking it into serving malicious content to everyone who visits a site.

This technique, known as web cache poisoning, transforms a single, targeted attack into a widespread problem affecting countless visitors with each request. A poisoned cache might distribute malware, steal credentials through injected scripts, or redirect traffic to fraudulent sites until the harmful entry is found and purged.

For developers and security professionals, recognizing and mitigating this threat is critical to protecting both users and infrastructure from significant harm.

Definition and Scope

Web cache poisoning is a sophisticated attack that targets the intermediary caches standing between a server and its users. An attacker manipulates a web application and its cache into storing a malicious response, which is then served to all subsequent visitors requesting that same resource.

This turns a system designed for performance into a distribution platform for harmful content, creating a significant security risk for any application that relies on caching.

What Is Web Cache Poisoning?

Web cache poisoning occurs when an attacker successfully gets a web cache to store a harmful HTTP response. The poisoned content remains in the cache and is delivered to legitimate users until the cache entry expires or is manually purged.

The attack works by exploiting discrepancies between the parts of a request a cache uses to store a response and the parts a web application uses to generate it. If an application uses an input that the cache ignores, an attacker can use that input to create a malicious response and have it stored under a generic cache key.

The Amplified Impact

The primary danger of this attack vector is its ability to scale. A single, well-crafted request from an attacker can compromise thousands of users.

It serves as a delivery mechanism for other attacks, turning a limited payload into a widespread threat. For example, a cross-site scripting (XSS) payload that would normally affect only one user can be stored in a poisoned cache, causing it to execute in the browser of every visitor. Similarly, an open redirect can be cached to send a steady stream of users to a malicious website.

Distinguishing from Similar Attacks

It is important to separate web cache poisoning from other caching-related attacks. It is not the same as DNS cache poisoning, which targets the Domain Name System by corrupting a DNS resolver’s cache to redirect traffic at the domain level.

It also differs from web cache deception, an attack where a user is tricked into visiting a specially crafted URL that causes their private information to be stored in a public cache, exposing it to others. Web cache poisoning is specifically focused on getting the cache to store a malicious response generated by the origin server itself.

Caching Models and Keys

Web caches are fundamental to modern web performance, reducing latency and server load by storing copies of responses closer to users. Their effectiveness depends on a strict set of rules that determine which content to save and for how long.

Attackers exploit the logic of these systems, turning a performance-enhancing tool into a security vulnerability by manipulating how content is stored and retrieved.

How Caches Boost Performance

A web cache works by intercepting requests for resources like HTML pages, images, and stylesheets. When a request is received, the cache checks if it has a valid, stored copy of the requested content.

If a copy exists (a cache hit), the cache delivers it directly to the user, bypassing the origin server entirely. If no copy is available (a cache miss), the request is forwarded to the server, and the cache stores the response before sending it to the user.

This process ensures that subsequent identical requests are served much faster, significantly improving the user experience and reducing the strain on backend infrastructure.

The Function of Cache Keys

To manage stored responses, a cache uses a cache key to create a unique identifier for each entry. A simple cache key might consist of the request method and the full URL path.

When a new request arrives, the cache generates a key from it and checks for a matching entry. Web cache poisoning succeeds when an application uses an input to generate a response, but that same input is not included in the cache key.

An attacker can submit a request with a malicious value in this “unkeyed” input, such as a custom HTTP header. The application generates a poisoned response, but the cache stores it under a generic key, making it the default response for all users.

Interpreting Cache Policies

Caches rely on HTTP headers from the server to guide their behavior. The Cache-Control header dictates whether a resource is cacheable and for how long it should be stored.

The Vary header is a critical signal for preventing poisoning, as it instructs the cache to create separate stored versions of a response based on the values of specified headers, like User-Agent or Accept-Language. By observing cache behavior, such as whether responses include headers like X-Cache: HIT or X-Cache: MISS, developers and testers can determine what content is being cached and how it is segmented across different types of requests.

Attack Mechanics

Executing a web cache poisoning attack is a deliberate, two-stage process that requires a careful manipulation of both the web application and the caching layer. An attacker must first trick the backend server into generating a harmful response and then ensure that response is stored by the cache.

Success depends on exploiting subtle inconsistencies in how different parts of the web infrastructure handle incoming requests.

The Two-Phase Process

The attack unfolds in two distinct phases. First, the attacker sends a carefully crafted request to the web server that includes a malicious payload.

The goal is to elicit a dangerous response, such as a page containing a cross-site script or a redirect to an external site. Second, the attacker must ensure this specific response is stored in a shared cache. If the cache key omits the header or parameter containing the payload, the poisoned response will be saved under a generic key.

From that point on, any user requesting the same resource will receive the attacker’s malicious version directly from the cache.

Common Attack Vectors

The most common vectors for web cache poisoning involve unkeyed inputs, particularly HTTP headers. Many applications use headers like Host, X-Forwarded-Host, X-Forwarded-Proto, or other non-standard headers to dynamically generate URLs, import scripts, or control application logic.

Caching systems, however, often fail to include these headers in the cache key by default. This creates a vulnerability where an attacker can supply a malicious value in one of these headers, alter the response from the server, and have it cached for all other users.

The response body, status code, or routing behavior can all be influenced by these unkeyed inputs.

Necessary Preconditions

Several conditions must be met for a web cache poisoning attack to succeed. The target resource must be configured to be publicly cached and shared among multiple users.

If a resource is marked as private or non-cacheable, the attack cannot proceed. The injected payload must also survive any input sanitization or output encoding performed by the application.

Finally, the response generated by the server must still be considered cacheable under the site’s existing policies. If the response contains an error or has headers that prevent caching, the poisoned content will not be stored.

Potential Impact of an Attack

When a web cache is poisoned, the consequences extend far beyond a single user’s browser. The attack amplifies harm by distributing malicious content to a broad audience, leading to a range of damaging outcomes.

From stealing user credentials on a massive scale to rendering a service completely unavailable, the impact can be severe and long-lasting.

Widespread Cross-Site Scripting

One of the most severe outcomes is the ability to launch a cross-site scripting (XSS) attack against every user of a web application. An attacker can poison a cache with a response containing a malicious script. This script is then delivered to all users who request the poisoned resource, executing in their browsers automatically.

Such scripts can be used to hijack user sessions by stealing authentication cookies, exfiltrate sensitive data entered into forms, deface the website with unauthorized content, or silently redirect users to phishing sites.

Malicious Redirects and Denial of Service

Cache poisoning can also be used to redirect traffic or disrupt service availability. An attacker might poison a cache entry with an HTTP redirect, forcing any user requesting a legitimate page to be sent to a malicious destination.

These destinations are often phishing websites designed to harvest credentials or pages that attempt to install malware. In a denial-of-service scenario, an attacker could cache a server error response, such as a “404 Not Found” or “503 Service Unavailable” page.

This makes the resource inaccessible to all users until the poisoned cache entry is purged, effectively taking a portion of the website offline.

Exposure of Sensitive Data

Improper cache configurations can lead to the accidental exposure of sensitive user data. If a page containing personalized information, such as account details or order history, is mistakenly stored in a shared cache, it can be served to other, unrelated users.

While not always the result of a malicious poisoning attempt, the mechanism is similar. One user’s private information is cached and then delivered to another, resulting in a serious data breach.

This type of leak undermines user privacy and can have significant legal and reputational consequences.

Detection and Testing

Identifying web cache poisoning vulnerabilities requires a systematic testing methodology. Proactive detection is essential for securing modern web applications, as these flaws are often subtle and arise from the complex interactions between different layers of technology.

The process involves mapping out the application’s caching behavior, probing for weaknesses, and confirming their exploitability in a controlled manner.

Mapping the Cache Attack Surface

The first step in testing is to identify which parts of an application are being cached. This involves manually browsing the website or using automated tools to crawl it while observing the HTTP headers of each response.

Pay close attention to headers like Cache-Control, Expires, and Pragma, which indicate the server’s caching intentions. Observing cache-specific headers, such as X-Cache: HIT or X-Cache: MISS, confirms how the cache is actually behaving.

The Vary header is also important, as it specifies which request headers should be used to segment the cache. This initial reconnaissance helps build a map of potentially vulnerable endpoints.

Finding Unkeyed Inputs

Once you have identified cacheable resources, the next phase is to hunt for unkeyed inputs that influence the application’s response. This is typically done through a process known as fuzzing, where you send a series of requests with slight variations to see if you can change the output.

The focus should be on adding or modifying non-standard HTTP headers that applications might use to construct URLs or content, such as X-Forwarded-Host, X-Forwarded-Proto, and X-Original-URL. If you can alter a response by adding one of these headers but the cache still serves a stored version on subsequent requests, you have likely found an unkeyed input.

Validating the Poisoning Vulnerability

Discovering an unkeyed input is not enough; you must confirm that it can be used to poison the cache for other users. The final step is to validate the vulnerability in a controlled environment.

First, send a request containing the malicious, unkeyed input to generate a poisoned response from the server and get it stored in the cache. Then, send a separate, clean request from a different user session or browser to the same URL.

If the second request receives the poisoned content, the vulnerability is confirmed. This proves that an attacker could successfully serve harmful content to legitimate users.

Prevention and Mitigation

Effective defense against web cache poisoning relies on a layered strategy that addresses vulnerabilities at the application, infrastructure, and operational levels. By implementing robust controls throughout the request-response lifecycle, developers and operators can significantly reduce the risk of an attacker successfully poisoning a cache.

Align Cache Keys or Avoid Caching

The most direct way to prevent cache poisoning is to eliminate the root cause: the discrepancy between inputs the application uses and inputs the cache acknowledges. If any part of a request, such as an HTTP header, can influence the response, it must be included in the cache key.

The Vary HTTP header is the standard mechanism for achieving this. By adding a header’s name to the Vary response header, you instruct the cache to create a separate cache entry for every different value of that request header.

Alternatively, for pages that are highly dynamic or reflect user input in ways that are difficult to track, the safest approach is to disable caching entirely. This can be accomplished by sending a Cache-Control: no-store header, ensuring that sensitive or user-specific content is never stored in a shared cache.

Sanitize Inputs and Encode Outputs

As a critical defense-in-depth measure, all user-controllable input must be rigorously sanitized, and all output must be properly encoded. This principle ensures that even if a poisoned response is successfully cached, its payload is rendered harmless.

Input sanitization involves validating and cleaning data as it enters the application to block malicious payloads before they are processed. Output encoding ensures that any data reflected back to the user is treated as literal text rather than executable code, which effectively neutralizes cross-site scripting (XSS) attacks.

Following these secure coding practices means that reflected content, even when cached, will not pose a threat to users.

Implement Edge Controls and Operational Readiness

The infrastructure sitting in front of a web application, such as a Content Delivery Network (CDN) or load balancer, offers a powerful point of control. Configure this edge layer to strip all unexpected or non-standard headers from incoming requests.

This practice removes many potential unkeyed input vectors before they can reach the application logic. It is also wise to enforce conservative caching policies by default, only enabling caching for resources that are known to be safe and static.

Finally, organizations must maintain operational readiness. This includes having robust monitoring to detect anomalies and a well-defined playbook for rapidly purging the cache when an incident is suspected, minimizing the duration and impact of any successful attack.

Conclusion

Web cache poisoning exploits the trust between a web application and its performance-enhancing caches, turning a tool for speed into a vector for widespread attacks. An effective defense requires a disciplined and multi-layered approach.

It begins with aligning cache keys to account for all inputs that influence a response, or by disabling caching altogether for dynamic content. Hardening the application with strict input sanitization and output encoding provides a critical safety net, neutralizing payloads even if they are cached.

Finally, strong edge controls and established operational procedures for monitoring and purging the cache ensure that any potential threats can be contained quickly. By applying these principles, organizations can protect their users and infrastructure, allowing web caches to serve their intended purpose as performance accelerators, not attack amplifiers.