Web Cache Poisoning & Deception

Written by Bar Hajby on

Web Cache Poisoning & Deception

Written by Bar Hajby on


Web caching is a vital mechanism that enhances website performance by reducing server load and improving page load times. It acts as an intermediary between a user’s web browser and the web server, which stores copies of web pages for faster access. However, as beneficial as web caching may be, it also introduces potential risks. Web cache poisoning threats involve malicious actors manipulating the cache to inject harmful content, and on the other hand, web cache deception deceives the system into serving compromised data. These attacks pose significant security concerns for website owners and users alike. Understanding and addressing these risks are essential topics we will explore further in this article.

Web Cache Poisoning

Web cache poisoning can occur through attack vectors that exploit vulnerabilities in web applications or misconfigurations in caching systems. One common method involves injecting malicious data into the cache by manipulating input parameters, such as URL parameters or HTTP headers. 

Attackers may use specially crafted requests that include harmful scripts or content. If the web application fails to validate and sanitize these inputs properly, the malicious content gets stored in the cache and associated with legitimate URLs. Subsequent users requesting the same URLs will unknowingly receive the poisoned content, potentially leading to the execution of malicious scripts, redirection to phishing sites, or unauthorized access to sensitive data. 

Additionally, attackers can take advantage of improperly configured cache control mechanisms, allowing the poisoned content to remain in the cache for an extended period, impacting multiple users.

Explanation of The Attack

To gain insight into the risks of Web Cache Poisoning and its sensitivity to exploitation for malicious purposes, we will present a real-world scenario that emerged during a penetration test. This scenario will highlight how we utilized Web Cache Poisoning to achieve unauthorized JavaScript code execution on the system’s users, leading to Cross-site Scripting (XSS) attacks.

At the beginning of our research, we thoroughly examined the targeted web application cache mechanism, delving into its cache keys and logic. Then, we tried appending different HTTP headers into a specific request, expecting the server to accept one of our attempts until we discovered a valid reflection in the response while using the X-Forwarded-Host header.

This action led to caching the header’s value into an Anchor HTML element within an href attribute. To successfully poison the cache with client-side code execution, our next goal is to escape the Anchor element into the DOM, which is a tree-like structure that represents web pages in web browsers, making it possible to interact with and change web page content using code like JavaScript in an attempt to affect the users without any interaction.

Web Cache Poisoning & Deception
The Header Value Embedded into the HTML DOM


As the system’s security mechanism filtered out essential characters for assembling the payload of the attack, such as “.”, “:” and upper case letters, we considered ways to overcome this challenge. Therefore, we used a minified JavaScript representation technique called “JSFu*k”, a method to represent JavaScript code using only six minimalistic characters. The payload of the JavaScript code contained an action to redirect users to arbitrary websites controlled by the attacker automatically and constructed as follows:


Web Cache Poisoning & Deception - JavaScript code cached
The Obfuscated JavaScript Code is Successfully Cached

Note: in this scenario, it is important to mention that we have concatenated an extra random query parameter (such as p=1 in this case) to the request to hide the cache poisoning from other users since all the query parameters are included in the cache key.


If you have replicated the above attack in your application, please consider the following instructions for immediate mitigation to prevent Web Cache Poisoning attacks:

  • Implement strict input validation and sanitization techniques on all user-provided data and parameters. This ensures that malicious input is detected and blocked before it can reach the cache and cause poisoning. For more information, refer to this article.
  • Web applications should focus on securely generating cache keys that are resistant to manipulation. Implementing strong cryptographic hashing algorithms to generate cache keys based on the complete request, including headers, cookies, and other sensitive information, is essential. For more information, refer to this article.

Web Cache Deception

A technique attackers use to manipulate caching systems and mislead users or web applications into serving unintended content. It involves crafting malicious requests to exploit vulnerabilities in caching mechanisms, leading to the caching of sensitive data associated with other users with legitimate URLs. 

Subsequent users who unknowingly request malicious URLs may unknowingly serve their highly confidential and personal sensitive information to the attacker without their explicit consent, thereby putting their privacy and security at significant risk.

Explanation of The Attack

We will present an attack diagram to gain insight into the risks of Web Cache Deception and its susceptibility to exploitation for malicious purposes. This case will highlight how to successfully utilize Web Cache Deception by caching non-existent JavaScript files, leading to unauthorized access to sensitive pages within the application for a prolonged time.

For this attack to be successful, three specific conditions must be met:

1. The web cache functionality of the web application should be configured to cache static files based on their extensions without considering any caching headers provided by the server. 

2. When accessing a page as “,” the web server must respond by serving the content of “home.php” for that particular URL, even though the requested CSS file “non-existent.css” does not exist.

3. The server doesn’t require authentication to access its public static files. Consequently, the cached files become publicly accessible without needing any authentication.


This cache was achieved by appending a non-existent JavaScript file to the URL, yet it still allowed access to the home page content and cached its content as a static file. Sending it to the victim as a phishing link potentially exposes valuable data since cached static files are available to everyone, including unauthenticated users, in the mindset of reducing the server load.

Web Cache Poisoning & Deception - exploitation
A Chart Explaining the Attack


If you have encountered the above scenario, please follow the instructions below provided by Clear Gate for immediate mitigation and to prevent Web Cache Deception attacks further:

  • Design and enforce strict caching policies tailored to your application’s needs. Use private caching for sensitive data that should not be cached by intermediate proxies, and utilize public caching for safe, shareable resources. Regularly review and update caching policies to adapt to changing security threats. For more information, refer to this article.
  • Adjust the web server configuration to handle pages like “” differently. When such URLs are accessed, the server should respond with a 404 or 302 response instead of serving the content of “MyAccount”. This will avoid unintentional content exposure and improve the application’s overall security. For more information, refer to this article.


Web cache poisoning and deception are significant security threats in the context of complex caching systems, which store copies of responses to reduce backend load. Improperly managed caches can unintentionally store malicious or manipulated content, leading to potential attacks such as cache poisoning on unsuspecting users. 

Mitigating the risks mentioned above required configuring robust input validation, secure caching policies, and appropriate headers to prevent the poisoning of cached content. Additionally, web applications must carefully manage cache eviction policies, ensuring that cached data is valid and intended for each user or session to counter web cache deception attacks. Regular cache monitoring and auditing are also essential to detect any signs of deception and take corrective actions promptly. By adopting these measures, web applications can enhance their security posture and safeguard their users’ data effectively against cache poisoning and deception threats.

Organizations should prioritize cyber security risk assessments and penetration tests to mitigate risks in web caching deployments, which have become increasingly popular among companies developing SaaS products. Clear Gate, a trusted cybersecurity provider, offers in-depth manual penetration tests to help organizations strengthen their web caching security and protect valuable data from potential threats.