Web applications rely on caching to improve performance, reduce server load, and deliver content quickly to users. Content Delivery Networks (CDNs), reverse proxies, and browser caches store frequently requested resources so that applications do not need to generate every response from the origin server.
However, incorrect cache configuration can introduce serious security weaknesses. Two important examples are web cache deception and web cache poisoning. Although both attacks involve manipulating how caches store and serve HTTP responses, they exploit different weaknesses and can have very different consequences.
Web cache deception can expose private information by tricking a cache into storing a personalized response under a URL that appears to reference a static resource. Web cache poisoning, on the other hand, allows an attacker to influence a response that gets stored and later delivered to other users.
These vulnerabilities are particularly relevant to applications that use CDNs, shared caching layers, dynamic routing, and complex HTTP request processing. Security professionals need to understand how the cache and origin server interpret requests, identify inconsistencies, and verify whether a response can be incorrectly stored or reused.
This guide explains web cache deception vs web cache poisoning, their differences, common attack scenarios, testing methodologies, and practical mitigation techniques.
What Is Web Caching?
Web caching is a technique that stores copies of HTTP responses so they can be reused when similar requests arrive.
For example, an e-commerce website may serve the same product image to thousands of visitors. Instead of retrieving the image from the origin server every time, a CDN can store it and deliver subsequent requests from a nearby cache location.
A typical web caching architecture contains:
- Client: The browser or application requesting a resource.
- CDN or reverse proxy: An intermediary that receives requests and may store responses.
- Cache storage: The location where reusable responses are kept.
- Origin server: The backend application responsible for generating the response.
How a Cache Key Works
A cache key identifies which requests should be treated as equivalent by a caching system.
Depending on the configuration, a cache key may include:
- Request URL
- Hostname
- Query string
- Selected HTTP headers
- Device or language information
- Other configured request properties
When another request matches an existing cache key, the cache may return the stored response instead of contacting the origin server.
This behavior improves performance, but it also creates security risks when the cache ignores information that changes the response or stores content that should remain private.
For example, suppose an application generates different responses based on a request header, but the cache does not include that header in its cache key. The cache may treat two different responses as equivalent.
This kind of mismatch is central to many cache security vulnerabilities.
What Is Web Cache Deception?
Web cache deception is a vulnerability in which an attacker tricks a caching system into storing sensitive or personalized content as though it were a static resource.
The attack generally relies on a difference between how the origin server and the cache interpret a URL.
For example, an authenticated application may return a private account page for:
GET /account/profile HTTP/1.1
Host: example.com
Cookie: session=USER_SESSIONThe application might also return the same profile page when it receives:
GET /account/profile/image.css HTTP/1.1
Host: example.com
Cookie: session=USER_SESSIONThis can happen when the origin server ignores the unexpected path suffix and routes both requests to the same profile handler.
However, the CDN may identify the second URL as a CSS resource because it ends in .css. If its caching rules allow CSS files to be stored, it may cache the personalized profile response.
An attacker who can subsequently request the same cache entry may receive the victim’s cached content.
How Web Cache Deception Works
A typical web cache deception attack follows these steps:
- The attacker identifies an authenticated endpoint that returns personalized information.
- The attacker discovers that the origin server accepts unexpected path segments or file extensions.
- The attacker creates a URL that looks like a static resource.
- The victim visits the crafted URL while authenticated.
- The origin server returns the victim’s personalized response.
- The cache stores the response because the URL matches its caching rules.
- Another request retrieves the stored response.
The impact depends on the content exposed and whether the cache entry can be accessed by another user.
Common Targets
Web cache deception can affect endpoints that return:
- User profile information
- Account details
- Private dashboards
- Order history
- Personal messages
- Internal application data
- Account-specific API responses
A successful attack may expose information that the application normally protects through authentication.
What Is Web Cache Poisoning?
Web cache poisoning occurs when an attacker manipulates an HTTP request to make the origin server generate an unintended response, which is then stored by a shared cache and served to other users.
The vulnerability often involves unkeyed inputs.
An unkeyed input is a request component that influences the origin response but is not included in the cache key.
For example, an application may use the X-Forwarded-Host header to generate an absolute URL in its response. However, the caching layer may not include that header when identifying the response.
If an attacker can control this header and influence a cacheable response, the application may generate content containing an attacker-controlled hostname.
If the cache stores that response under a key shared with normal visitors, other users may receive the manipulated content.
How Web Cache Poisoning Works
A typical web cache poisoning attack involves three main stages:
- Identify unkeyed inputs: Find request headers, cookies, or other inputs that influence the response but are not represented in the cache key.
- Influence the origin response: Determine whether the input can produce a harmful response, such as an injected script, unexpected redirect, or manipulated page content.
- Get the response cached: Establish whether the cache stores the response and serves it to other requests with the same cache key.
The attack can affect multiple users if the poisoned response is stored in a shared cache.
Common Unkeyed Inputs
Depending on the application and cache configuration, possible inputs include:
X-Forwarded-HostX-Forwarded-SchemeX-Original-URLX-Rewrite-URL- Unkeyed custom HTTP headers
- Cookies ignored by the cache key
- Query parameters excluded from the cache key
- Other request metadata used by the origin application
These inputs are not automatically vulnerable. A security issue exists only when an input can influence a cacheable response in a way that creates an exploitable difference.
Web Cache Deception vs Web Cache Poisoning: Key Differences
Both vulnerabilities involve incorrect cache behavior, but their attack goals and exploitation methods are different.
| Comparison | Web Cache Deception | Web Cache Poisoning |
|---|---|---|
| Primary objective | Expose private cached content | Store a manipulated response |
| Main weakness | Cache and origin interpret URL paths differently | Origin uses input that cache does not include in its key |
| Typical target | Authenticated or personalized pages | Shared cacheable responses |
| Common attack technique | Add a static-looking path suffix | Manipulate unkeyed headers or parameters |
| Main security impact | Confidentiality breach | Integrity compromise |
| Potential result | Exposure of account information | XSS, malicious redirects, or altered content |
| Key testing focus | URL parsing and cache eligibility | Unkeyed inputs and cache-key behavior |
The Main Difference: Confidentiality vs Integrity
The simplest way to understand the difference is to examine what the attacker wants to achieve.
In web cache deception, the attacker wants the cache to store information that should remain private. The primary concern is confidentiality.
In web cache poisoning, the attacker wants the cache to store a response that has been manipulated. The primary concern is integrity.
Both vulnerabilities can have serious consequences. The actual impact depends on the application’s functionality, the cache architecture, and the content being stored.
Why These Vulnerabilities Matter
Modern applications often use multiple caching layers. A single request may pass through a browser cache, CDN, reverse proxy, web server, and application framework.
Each component may process URLs, headers, cookies, and response instructions differently.
This complexity creates opportunities for security misconfigurations.
Sensitive Information Exposure
A web cache deception vulnerability may expose information from authenticated sessions.
For example, a user may visit a crafted profile URL while logged in. If the CDN stores the personalized response and later serves it to another visitor, private information may become accessible.
Cross-Site Scripting Through Cached Responses
Web cache poisoning can sometimes be used to distribute malicious content.
If an attacker-controlled header is reflected into an HTML response without proper validation or encoding, the attacker may be able to poison a shared cache with a response containing malicious script.
Visitors who receive that cached response may execute the injected content in their browsers.
Malicious Redirects
An application may use untrusted request headers to construct redirect URLs.
If the response is cacheable and the relevant header is not part of the cache key, an attacker may cause a redirect response to be stored and reused.
Cross-User and Cross-Tenant Data Leakage
Applications that serve multiple users or organizations must ensure that personalized content is not reused across unrelated sessions or tenants.
If the cache key does not account for the required security context, one user may receive another user’s data.
Business and Reputation Damage
Cache vulnerabilities can affect more than technical infrastructure.
They may expose customer information, damage trust, interrupt application availability, or create compliance concerns.
Common Web Cache Deception Attack Techniques
1. Static Extension-Based Cache Deception
Some caching configurations use file extensions to decide which resources should be cached.
Common examples include:
.css.js.jpg.png.gif
If an origin server ignores unexpected path suffixes, an attacker may append one of these extensions to a dynamic endpoint.
For example:
GET /account/settings/profile.css HTTP/1.1
Host: example.com
Cookie: session=USER_SESSIONIf the origin server returns the normal profile page while the cache treats the URL as a CSS resource, the response may be stored incorrectly.
2. Path Mapping Discrepancies
Different application components may normalize or map URL paths differently.
For example, the CDN may interpret a path as one resource while the backend framework routes it to another handler.
Testers should examine:
- Unexpected path segments
- Trailing slashes
- Encoded path characters
- Repeated separators
- Case normalization
- Framework-specific routing behavior
The goal is to identify whether the cache and origin server disagree about the resource being requested.
3. Delimiter and URL Encoding Discrepancies
URL delimiters can be processed differently by intermediaries and origin servers.
Encoded characters such as %3F or %23 may be decoded at different stages of request processing.
If the cache applies its rules before decoding while the origin server interprets the decoded path differently, a URL may be treated as a cacheable resource by one component and a dynamic endpoint by another.
These tests should be performed carefully because URL normalization behavior varies between platforms.
Common Web Cache Poisoning Attack Techniques
1. Unkeyed Header Manipulation
An application may use request headers to generate absolute links, redirects, or other response content.
For example:
GET /home HTTP/1.1
Host: example.com
X-Forwarded-Host: attacker.exampleIf the application trusts the header and uses it to generate a link, the response may contain the supplied hostname.
If the cache ignores that header when creating the cache key, a manipulated response could be reused for normal visitors.
2. Unkeyed Query Parameters
Some caching systems ignore selected query parameters or exclude the entire query string from their cache key.
If the origin application still processes those parameters, the response may vary even though the cache treats the requests as equivalent.
For example, an application may generate different page content based on a query parameter that the CDN ignores.
A tester should verify whether the parameter changes the response and whether the cache distinguishes the resulting requests.
3. Cache Key Normalization Issues
Caching systems may normalize URLs, filter parameters, or transform request components before generating a cache key.
If the origin receives a different representation from the one used by the cache, the two systems may disagree about which response belongs to a particular request.
These inconsistencies can create cache poisoning opportunities.
4. Host and Scheme Manipulation
Some applications use host and scheme information to construct redirects, canonical URLs, or links.
If the application trusts unvalidated forwarded headers, an attacker may influence generated response content.
The risk increases when these values affect cacheable responses and the relevant inputs are not represented correctly in the cache key.
How to Test Web Cache Deception Vulnerabilities
A structured testing process helps security professionals identify cache behavior without exposing real users to unnecessary risk.
Testing should be performed only on systems for which explicit authorization has been provided. Prefer a staging environment, test accounts, and cache entries that cannot affect other users.
Step 1: Identify Dynamic and Authenticated Endpoints
Start by mapping the application’s important routes.
Look for endpoints that return user-specific or sensitive information, such as:
/account/profile/dashboard/settings/orders/messages
Review the application’s behavior while authenticated and unauthenticated.
Identify which endpoints return different responses depending on the active user session.
Step 2: Understand the Caching Behavior
Inspect response headers for caching information.
Common headers include:
Cache-Control: private, no-store
Vary: Cookie
Age: 120
ETag: "abc123"Other useful indicators include:
ExpiresLast-ModifiedCDN-Cache-StatusX-CacheCF-Cache-Status
The exact headers depend on the caching provider and application architecture.
A header such as Age or a provider-specific cache status may help identify whether a response came from a cache. However, the absence of a visible cache header does not prove that no intermediary cache exists.
Step 3: Test Static-Looking URL Variations
In a controlled environment, examine whether an authenticated endpoint accepts unexpected path suffixes.
For example, compare:
GET /account/profile HTTP/1.1with:
GET /account/profile/test.css HTTP/1.1Observe whether the origin returns the same personalized content.
Do not assume that a successful response indicates a vulnerability. The next step is to determine whether the caching layer actually stores that response.
Step 4: Verify Cache Storage
Use a controlled test account and a unique test URL.
Send the request and inspect the response headers. Then repeat the request in a way that allows you to identify a cache hit or miss.
If possible, verify the result using the CDN dashboard or cache logs.
The important question is whether the cache stores personalized content and whether another session can retrieve it.
Step 5: Verify Cross-Session Exposure Safely
Use two authorized test accounts with different profile data.
For example:
- Account A has a unique test value in its profile.
- Account B has a different test value.
- Account A requests the crafted URL.
- Account B requests the same cache key in the controlled environment.
If Account B receives Account A’s personalized content, the issue may represent a confirmed cache deception vulnerability.
Use synthetic information only. Never attempt to retrieve another real user’s private information.
How to Test Web Cache Poisoning Vulnerabilities
Cache poisoning testing focuses on identifying request inputs that influence responses without being represented in the cache key.
Step 1: Identify Cacheable Responses
Start with pages and API endpoints that may be stored by a shared cache.
Review their response headers, cache status, content type, and behavior when the same request is repeated.
Focus on responses that are intentionally cacheable or appear to be cached by the CDN.
Step 2: Identify Unkeyed Inputs
Use an intercepting proxy to inspect the request and test whether selected headers influence the response.
For example, compare the normal response with a controlled request containing a harmless test header:
GET / HTTP/1.1
Host: example.com
X-Test-Header: cache-audit-123Observe whether the value appears in the response body, headers, generated links, or redirects.
A reflected input is not automatically a vulnerability. You must establish whether it affects a response that can be stored under a cache key shared with requests that do not contain the test input.
Step 3: Examine the Cache Key
Determine which request components the caching system uses to identify a response.
Depending on the platform, this may require:
- CDN cache configuration
- Reverse proxy configuration
- Cache logs
- Provider-specific debugging headers
- Cache simulation or rules tools
Check whether the tested header, cookie, or query parameter is included in the cache key.
Step 4: Use Cache Busters
During testing, use unique cache-busting values where the platform permits them.
This helps distinguish a fresh origin response from an existing cached response.
However, make sure the cache-busting component is actually part of the cache key. If the cache ignores it, it may not isolate your test response.
PortSwigger’s research on practical web cache poisoning explains why cache behavior and unkeyed inputs must be investigated together.
Step 5: Validate the Impact
If an input changes a response, determine whether the result could cause a meaningful security impact.
Examples include:
- Unexpected external links
- Manipulated redirects
- Reflected script content
- Incorrect page content
- Security-sensitive response headers
In a live environment, do not attempt to poison a shared cache with harmful content. Use a private test cache, isolated hostname, or staging environment and harmless markers.
Step 6: Document the Results
A useful report should include:
- Affected endpoint
- Cache provider or intermediary, if known
- Relevant request and response evidence
- Cache key behavior
- Input that changes the origin response
- Whether the response is stored
- Expected and observed behavior
- Potential impact
- Recommended remediation
Tools Used for Cache Security Testing
1. Burp Suite
Burp Suite helps testers intercept, modify, and replay HTTP requests.
Useful features include:
- Proxy for capturing requests and responses
- Repeater for controlled request comparisons
- Comparer for analyzing response differences
- Param Miner for discovering potential unkeyed inputs
Param Miner is particularly useful during web cache poisoning assessments because it can help identify hidden request inputs that influence application responses.
2. OWASP ZAP
OWASP ZAP is an open-source web application security testing tool.
It can help inspect HTTP traffic, identify application behavior, and automate parts of an authorized security assessment.
Manual cache analysis is still necessary because generic scanning does not reliably identify every cache key or routing discrepancy.
3. Browser Developer Tools
Browser developer tools provide useful information about HTTP requests, response headers, resource loading, and browser caching.
They can help identify:
- Cache-related response headers
- Resource paths
- Redirect behavior
- Session-dependent responses
- Browser cache behavior
4. CDN Configuration and Logs
CDN dashboards and logs are valuable when testing the actual caching layer.
Depending on the provider, these tools may reveal:
- Cache hit and miss status
- Cache key configuration
- Cache eligibility rules
- Origin response headers
- Cache purge activity
5. Command-Line HTTP Tools
Tools such as curl can help compare responses and inspect HTTP headers.
For example:
curl -i https://example.com/A tester can use controlled request variations to compare how the origin and caching layer behave.
Command-line tools are useful for repeatable testing, but the results should be interpreted alongside the application’s routing and cache configuration.
How to Prevent Web Cache Deception
The best defense is to ensure that private or personalized responses are never stored in a shared cache unless the architecture explicitly supports secure, correctly partitioned caching.
1. Use Correct Cache-Control Headers
For sensitive authenticated responses, use appropriate directives.
For example:
Cache-Control: private, no-storeprivate indicates that shared caches should not store the response. no-store instructs caches not to store it.
These directives serve different purposes. For highly sensitive responses, using both provides a clear instruction to intermediaries and clients.
Do not rely only on frontend behavior to protect private content.
2. Validate URL Paths at the Origin
The origin application should reject unexpected path segments and suffixes when they do not belong to a valid route.
For example, if /account/profile is a dynamic endpoint, the application should not silently treat /account/profile/image.css as the same resource unless that behavior is explicitly intended.
3. Avoid Extension-Only Cache Rules
Do not decide whether a response is safe to cache solely because the URL ends in .css, .js, or .jpg.
Use explicit route-based cache policies and verify that the response content type matches the expected resource.
4. Keep Static and Dynamic Routes Separate
Where practical, serve static assets from a dedicated hostname or clearly separated path namespace.
For example:
static.example.comfor public assetsapp.example.comfor authenticated application routes
This separation can make cache policies easier to understand and maintain.
5. Test Path Normalization
Ensure that the CDN, reverse proxy, web server, and application framework interpret URL paths consistently.
Review encoded characters, delimiters, repeated separators, and unexpected suffixes.
How to Prevent Web Cache Poisoning
Cache poisoning prevention requires control over which request inputs influence responses and which inputs form the cache key.
1. Do Not Trust Unvalidated Forwarded Headers
Headers such as X-Forwarded-Host and X-Forwarded-Proto should only be trusted when they are supplied or replaced by a trusted proxy.
The origin application should not blindly accept these values from arbitrary clients.
Use an allowlist of valid hostnames and schemes.
2. Include Relevant Inputs in the Cache Key
If a request header or query parameter changes the response, the cache must distinguish requests that produce different content.
Depending on the caching platform, this may require custom cache keys or the appropriate Vary response header.
However, adding every possible header to the cache key is not always practical. The better approach is to avoid using unnecessary or untrusted request inputs when generating shared cacheable responses.
3. Cache Only Responses Intended for Public Reuse
Prefer explicit allowlists for cacheable routes.
Avoid caching dynamic pages that depend on:
- Authentication state
- User-specific cookies
- Private request headers
- Account permissions
- Tenant-specific information
4. Sanitize and Validate Reflected Inputs
Do not insert untrusted request metadata directly into HTML, JavaScript, redirects, or response headers.
Use context-appropriate output encoding and validate hostnames, URLs, and other security-sensitive values.
5. Keep Cache and Origin Normalization Consistent
Ensure that both systems use compatible URL normalization and request parsing behavior.
When the cache key is based on one representation but the origin processes another, attackers may be able to create unexpected cache collisions.
6. Purge Poisoned Cache Entries
If a cache poisoning incident occurs:
- Identify the affected cache keys and resources.
- Purge the affected entries across relevant cache layers.
- Fix the underlying input handling or cache key configuration.
- Verify the origin response and cache behavior.
- Monitor for repeated attempts.
Purging alone is not a permanent fix. The underlying vulnerability must be corrected before normal caching resumes.
Best Practices for Secure Cache Configuration
Security teams should treat caching as part of the application’s security architecture, not merely a performance feature.
The following practices help reduce cache-related risks:
- Define explicit cache policies: Document which routes can be cached and which must bypass shared caching.
- Protect authenticated responses: Use appropriate
Cache-Controldirectives for private data. - Review cache keys: Confirm that every input capable of changing a shared response is handled safely.
- Validate forwarded headers: Trust proxy metadata only from known infrastructure.
- Use route allowlists: Avoid relying solely on file extensions to determine cache eligibility.
- Normalize URLs consistently: Align CDN, proxy, and origin behavior.
- Inspect response content types: Make sure static-looking URLs return the expected resource type.
- Test multi-user behavior: Use separate test accounts to identify cross-session data exposure.
- Review CDN configuration changes: Treat cache rules as security-sensitive configuration.
- Monitor cache anomalies: Investigate unexpected redirects, content changes, and unusual cache hit patterns.
Teams should also include cache security testing in regular application security assessments, particularly after CDN migrations, routing changes, or major application updates.
Career Opportunities in Web Application Security Testing
Web cache security is a valuable topic for professionals working in web application penetration testing, API security, and infrastructure security.
Understanding these vulnerabilities requires knowledge of HTTP, caching behavior, request routing, reverse proxies, CDNs, and application logic.
Security professionals who can identify cache key weaknesses, analyze URL normalization, and verify cross-user data exposure can provide meaningful value during VAPT engagements.
Beginners can build a strong foundation through “https://academy.pentesthint.com/” practical cyber security learning and authorized “https://vuln.pentesthint.com/” cyber security labs.
Hands-on experience with Burp Suite, HTTP headers, CDN configuration, and application testing is especially useful for developing these skills.
Future Scope of Cache Security
Modern web architectures increasingly depend on distributed caching, edge computing, API gateways, and serverless applications.
These technologies improve performance but also introduce additional layers that process and store HTTP responses.
A request may pass through multiple caches, each with different rules for URL normalization, request headers, authentication, and cache expiration.
This makes consistent cache behavior increasingly important.
Future cache security assessments will likely focus on:
- Multi-layer cache key consistency
- CDN and origin request normalization
- API response caching
- Multi-tenant cache isolation
- Authentication-aware caching
- Edge computing security
- Cache invalidation and purge controls
- Automated cache configuration testing
Organizations should review cache policies as part of secure application design and infrastructure management.
Frequently Asked Questions (FAQs)
What is the difference between web cache deception and web cache poisoning?
Web cache deception tricks a caching system into storing private or personalized content under a URL that appears to reference a static resource. Web cache poisoning manipulates a response so that a harmful version is stored and served to other users. Deception primarily threatens confidentiality, while poisoning primarily threatens integrity.
How does a web cache deception attack work?
An attacker identifies a dynamic endpoint that returns authenticated information and finds a URL parsing discrepancy between the cache and origin server. A crafted URL may look like a static asset to the cache while the origin returns personalized content. If the cache stores that response and another user can retrieve it, private information may be exposed.
What is an unkeyed input in web cache poisoning?
An unkeyed input is a request component that influences the origin server’s response but is not included in the cache key. Examples may include certain HTTP headers, cookies, or query parameters. If the input changes a cacheable response, it may create an opportunity for cache poisoning.
Can web cache poisoning lead to cross-site scripting?
Yes. If an attacker can influence a cacheable HTML response through an unkeyed input and the application fails to encode the value correctly, the poisoned response may contain executable script. Other visitors who receive the cached response may execute that script.
How can I test web cache deception using Burp Suite?
Use Burp Suite to capture authenticated requests, identify dynamic endpoints, and compare normal URLs with static-looking path variations. Then inspect cache-related headers and verify the behavior using controlled test accounts. Always confirm whether the cache actually stores the personalized response before reporting a vulnerability.
Which HTTP headers are important when testing web cache vulnerabilities?
Common headers include Cache-Control, Vary, Age, Expires, ETag, X-Cache, and provider-specific cache status headers. During poisoning assessments, testers may also examine forwarded headers such as X-Forwarded-Host and X-Forwarded-Proto. Their presence alone does not establish a vulnerability.
How can organizations prevent web cache deception?
Organizations should prevent shared caching of sensitive responses, use appropriate Cache-Control directives, validate URL paths at the origin, and avoid relying only on file extensions to determine cache eligibility. CDN and origin URL handling should also be tested for consistency.
How can organizations prevent web cache poisoning?
Organizations should avoid allowing untrusted request inputs to influence shared cacheable responses. They should validate forwarded headers, use appropriate cache keys, apply context-aware output encoding, cache only intended public resources, and keep CDN and origin request processing consistent.
Conclusion
Web cache deception and web cache poisoning both exploit weaknesses in how applications and caching systems process HTTP requests and responses. However, their attack goals are different. Cache deception can expose private information by storing personalized responses under misleading URLs, while cache poisoning can distribute manipulated responses to other visitors.
Effective protection requires more than enabling basic CDN security settings. Organizations must understand their cache keys, control which responses are eligible for caching, validate request metadata, and ensure that the origin server and caching layer interpret URLs consistently.
For penetration testers, the most important steps are to identify sensitive endpoints, inspect cache behavior, test URL and input handling, and verify the actual impact using controlled sessions. For developers and infrastructure teams, secure cache policies and regular configuration reviews should be part of the application security lifecycle.
To strengthen your web application security testing process, explore “https://pentesthint.com/” PentestHint for cybersecurity resources and professional security assessment support. A correctly configured cache protects both application performance and user data.
