Web cache poisoning occurs when an attacker tricks a website’s cache into storing a harmful response and serving it to other visitors. The attack can affect many users without requiring each person to visit a malicious link. Security teams can reduce this exposure by testing cache rules, checking how applications handle requests, and validating whether attackers can influence cached content.
What Is Web Cache Poisoning?
Web cache poisoning is a web security attack that targets the way websites store and reuse responses.
Websites often use caches to improve speed and reduce server load. Instead of generating the same response for every request, a cache stores a copy and serves it again when another matching request arrives.
Content delivery networks (CDNs) use this approach to deliver content from servers closer to users. Web servers and applications can also cache responses to improve performance.
However, caching introduces a security risk when the cache and the application interpret a request differently.
An attacker may manipulate part of a request to make the application generate a harmful response. If the cache stores that response under a key shared by other users, it can serve the harmful content to them as well.
The impact depends on what the attacker can make the application return. Possible outcomes include unwanted redirects, injected scripts, and changes to website content.
The core problem is simple: a cache stores a response that should never have been shared with other visitors.
For a technical overview, see PortSwigger’s guide to web cache poisoning.
How Web Caches Work
To understand the attack, it helps to understand normal caching.
When a user requests a page, the cache checks whether it already holds a suitable response.
- Cache hit: The cache has a matching response and serves it.
- Cache miss: The cache does not have a matching response, so it sends the request to the application or origin server.
- Stored response: Depending on the caching rules, the cache saves the response for later requests.
This process works well when the cache stores the correct content and serves it only to the right users.
Problems arise when the cache treats two different requests as equivalent even though the application handles them differently.
What is a cache key?
A cache key identifies which requests can share a stored response.
It often includes the request path, host, and query string. Some systems also use selected request headers or other details.
However, not every part of a request is always included.
If an application uses a request value to build a response but the cache ignores that value when creating its key, an attacker may be able to influence what gets stored.
For example, a website might use a request header to build an absolute URL in a page. If the application trusts that header but the cache does not include it in the key, the response may contain attacker-controlled content.
If the cache stores that response and serves it to other visitors, the attack can affect more than the person who sent the original request.
How Attackers Poison a Web Cache
A successful attack usually involves three conditions.
1. The attacker finds an input that changes a response
First, the attacker looks for a request value that affects the content returned by the application.
This could be a header, a query parameter, or another input used to build the response.
The input becomes a concern when the application accepts it in an unsafe way.
2. The cache ignores that input
Next, the attacker checks whether the cache includes that input in its cache key.
If the application responds differently to the input but the cache treats both requests as equivalent, the attacker may be able to influence a shared cache entry.
This mismatch creates the opportunity for poisoning.
3. The cache stores and serves the harmful response
Finally, the attacker causes the application to return harmful content and gets the cache to store it.
Other visitors who make matching requests may then receive the poisoned response.
The attack can continue until the cache entry expires, someone removes it, or the caching rules change.
Not every website is vulnerable to this sequence. The attacker needs a suitable input, a way to influence the response, and caching behaviour that allows the harmful response to reach other users.
What Can Web Cache Poisoning Do?
The impact depends on the application, the input the attacker can control, and the response that gets cached.
Inject harmful scripts
If an attacker can cause a cached page to include untrusted JavaScript, visitors may receive and execute that script in the website’s context.
This can create a cross-site scripting (XSS) risk. The actual impact depends on browser protections, the page’s security controls, and what the injected script can access.
Redirect visitors to another site
An attacker may manipulate a response so that visitors receive an unwanted redirect.
This can support phishing campaigns or send users to a malicious website while making the initial link appear trustworthy.
Change website content
In some cases, an attacker can alter content served from a cached page.
The result may be false information, unwanted page changes, or content that damages user trust.
Affect many visitors
The shared nature of caching makes this attack particularly important.
A normal vulnerability may affect a single request or user. A poisoned cache entry can affect many visitors who request the same cached resource.
However, the scale depends on the cache configuration, the affected page, and how long the poisoned response remains available.
Why Traditional Security Scans May Miss It
Automated vulnerability scans can identify known weaknesses, insecure configurations, and other warning signs. However, web cache poisoning often depends on how several components handle the same request.
The cache may interpret a URL or header one way, while the application processes it another way.
A scanner may identify the application and report common weaknesses without proving that this mismatch creates an exploitable attack.
The testing process therefore needs to examine how requests travel through the full web stack.
Security teams should consider:
- Which request values influence the response
- Which values form the cache key
- Whether the cache and application interpret requests consistently
- Which responses the cache stores
- Whether a changed response reaches other users
- Whether the issue can be reproduced safely
This is where web application security testing adds value. Testing should examine how the application behaves in practice, not just whether it contains a known weakness.
How to Reduce Web Cache Poisoning Risk
Preventing web cache poisoning requires careful control over both application behaviour and caching rules.
Validate request inputs
Applications should not blindly trust headers or other request values when building links, redirects, or page content.
Use trusted configuration values where possible. Validate inputs and apply suitable output encoding to prevent untrusted data from changing the response in unsafe ways.
Set clear caching rules
Define which resources can be cached and under what conditions.
Public, static resources are often suitable for caching. Pages containing user-specific information or other sensitive content need stricter rules.
Use appropriate HTTP cache directives, such as Cache-Control: private or Cache-Control: no-store, when responses should not be shared or stored.
These directives need to match the application’s requirements and the behaviour of the caching infrastructure.
Review cache keys
Check that the cache key includes the request elements that affect the response.
If a header changes the content, but the cache ignores it, the cache may serve the wrong response to other users.
Avoid relying on request values that are not safely handled throughout the request path.
Test the full request path
Web applications often sit behind several layers, including CDNs, reverse proxies, load balancers, and application servers.
Each layer may process requests differently.
Therefore, test how the complete request path behaves. Check whether the cache and origin server agree on request handling, response content, and caching decisions.
Retest after changes
A configuration change can introduce a new mismatch or leave an earlier weakness unresolved.
After changing cache rules, application logic, or request handling, test the affected behaviour again.
Continuous service validation can support an ongoing approach to checking whether security weaknesses remain exploitable after changes.
How to Validate Web Cache Poisoning Exposure
Finding a suspicious caching rule is not the same as proving an attack is possible.
Validation should establish whether an attacker can influence a response, whether the cache stores it, and whether the stored response reaches other users.
A controlled test should answer four questions:
- Can an untrusted request value change the application response?
- Does the cache ignore that value when creating its cache key?
- Can the resulting harmful response enter the shared cache?
- Can another matching request receive that response?
Testing should take place in an authorised environment. On a live website, an unsafe test could affect real visitors by placing harmful content into a shared cache.
Use a test environment where possible. If production testing is necessary, agree on a controlled method that prevents test responses from reaching other users.
The final result should include evidence of the behaviour, the affected resources, the conditions required for exploitation, and the steps needed to fix the issue.
This gives security teams a stronger basis for remediation than a warning about a possible caching problem.
From Caching Errors to Proven Exposure
Web cache poisoning shows how a performance feature can become a security weakness when different parts of a website handle requests inconsistently.
A cache may work as designed in most situations and still create an exploitable flaw under specific conditions.
For that reason, security teams should not rely only on configuration reviews or generic scan results. They need to understand how the application and cache behave together, then test whether an attacker can influence content served to other users.
This approach also supports a broader attack surface management strategy. Discovering exposed applications is important, but teams also need to understand which weaknesses create a real path to harm.
The goal is not to flag every possible issue. It is to find the weaknesses that matter, prove their impact, and confirm that remediation works.
Frequently Asked Questions
What is web cache poisoning?
Web cache poisoning is an attack where an attacker causes a cache to store a harmful response and serve it to other visitors. It often occurs when the application uses request data that the cache ignores when deciding which requests can share a response.
What is the difference between cache poisoning and cache deception?
Cache poisoning causes a cache to store a harmful response that can affect other visitors. Cache deception tricks a cache into storing sensitive content that should not be shared. Both involve differences in how the cache and application handle requests, but their goals and outcomes differ.
How can organisations prevent web cache poisoning?
Organisations can reduce risk by validating request inputs, using safe caching rules, reviewing cache keys, and checking how the cache and application process requests. They should also retest after changes and avoid sharing responses that contain user-specific or sensitive data.
Can vulnerability scanners find web cache poisoning?
Scanners may identify clues, but they do not always prove that a cache can be poisoned. Testing needs to establish whether an attacker can change a response, get it stored, and cause other visitors to receive it. Safe validation provides stronger evidence of exploitability.
Request an Attack Insights Demo
Find exposed web applications, validate weaknesses, and focus remediation on the issues attackers can actually exploit.
