The fastest part of your application may also be the least inspected. CDN caches are designed to reduce latency by serving cached content closer to users while significantly reducing the load on origin servers. However, caches are not inherently aware of the sensitivity or security context of the content they store. Attackers can exploit gaps between application behavior and cache behavior, turning a performance optimization into a practical attack surface with real-world consequences.
To serve content efficiently, a CDN determines whether requests can share a cached response using a cache key, typically based on elements such as the host, URL path, query parameters, and selected request headers. The challenge arises when the CDN's understanding of a request differs from how the origin application processes it. An application may use additional request attributes such as headers, cookies, query parameters or URL structure to determine the response, while those attributes may not be reflected in the cache key.
This creates a gap between what the origin considers different requests and what the cache considers the same request. If cache behavior is not aligned with application logic, an attacker may be able to influence what is stored in the cache or cause content intended for one user or request context to be served to another.
These weaknesses are particularly relevant to two major attack classes: web cache poisoning and web cache deception. Both exploit inconsistencies between cache behavior and origin-side request processing, but they do so in different ways.
Why Organizations Cannot Afford to Ignore This Today
This is not just another security issue to keep on the radar for later. It deserves attention now because a number of subtle shifts in how applications, CDNs and caching infrastructures operate have changed the risk landscape, often without organizations realizing it.
First, caching got more aggressive. CDNs increasingly cache responses that used to be considered strictly dynamic, because the performance gain is real and the tooling to do it safely lagged behind the tooling to do it at all where security fails.
Second, the research caught up. What used to be a handful of academic papers on cache timing is now a documented, repeatable technique with public writeups against real production sites. AI-assisted reconnaissance and vulnerability research can further accelerate this process, lowering the effort required to discover weak cache assumptions and identify attack paths.
Third, and this is the part that matters operationally: when these failures happen, they don't look like a typical incident. There's no malware alert, no failed login spike, no obvious error in the logs. A poisoned cache entry just sits in the CDN serving the wrong thing to everyone, quietly, until someone notices the support tickets piling up about a script that shouldn't be on the homepage. The operational failure isn't a crash. It's silence in exactly the place you'd expect noise.
The cache key: The one concept worth actually understanding
Every cache, regardless of vendor, decides what counts as "the same request" using something called a cache key think of it as the label the photocopier reads before deciding whether it already has a copy. That label is usually built from the URL, the host, and sometimes a few headers or query parameters.
The problem is that plenty of things influence what your application returns without ever making it onto that label. A header like X-Forwarded-Host, a tracking parameter like utm_source, a session cookie and the origin server reacts to all of these, but the cache, reading only its label, never sees them. Security people call these unkeyed inputs. Everything below follows from that one gap. Now let's discuss 2 major security issues that evolve when your cache management fails.
Cache Poisoning: Turning the cache into an attack distribution mechanism
Figure 1: One forged header, reflected once by the origin, gets cached under a key that never saw it so every visitor afterward inherits the same poisoned response.
Plenty of applications build absolute URLs for canonical tags, script sources, redirects by trusting a header instead of hardcoding the domain. If an attacker sends a request like below which is demonstrated in the 'Figure 1':
GET /homepage HTTP/1.1
Host: victim.com
X-Forwarded-Host: attacker.com
and the application reflects that header into the page such as, into a script tag while the cache's label is built only from the path and host, the result is a page containing a script tag pointing at the attacker's domain, stored under the cache's normal entry for /homepage. Every visitor after that gets served the poisoned version until the entry expires (Cache Expires). One request and the damage compounds with every page view that follows. There's no breach to detect because nothing was breached the application behaved exactly as written, and the cache behaved exactly as written. The vulnerability lives entirely in the gap between the two.
Cache Deception: Tricking the cache into serving private content as public content
Figure 2: The origin ignores the .css suffix and returns the victim's real account data; the cache reads the same suffix and assumes it's safe to store — so the attacker just has to ask for it again.
This one runs the same gap in reverse as illustrated in 'Cache Poisoning'. Instead of pushing malicious content in, the attacker tricks the cache into storing something private that should never have left the building.
Picture a banking site as shown in the 'Figure 2'. An attacker sends a victim a link that looks harmless:
https://mybank.com/account/balance.css
The application's router doesn't care about file extensions, it sees /account/balance, checks the victim's session and returns the actual balance and account details. The cache, on the other hand, looks at that .css suffix and concludes this must be a static stylesheet, safe to store and replay to anyone. Nothing on the victim's screen looks wrong, the page renders fine. But her private response is now sitting on a shared cache entry. The attacker requests the identical URL Seconds/Minutes later and gets the victims account data back, no login required, because as far as the cache is concerned, this is just a CSS file it already has a copy of. One clicks from one victim is the entire attack surface. No password to steal, no server to compromise just a label the cache trusted that it shouldn't have.
Detection and Prevention Tactics
Protecting against these attack vectors calls for layered defenses that extend across cache key configuration, header handling, URL normalization and origin server logic. Conventional caching setups fall short on their own, since both attacks exploit the gap between how a cache interprets a request and how the origin server actually processes it. The table below outlines how detection and prevention tactics apply specifically to web cache poisoning and web cache deception.
| Attack Vector |
Detection Tactics |
Prevention Tactics |
| Web Cache Poisoning |
- Monitor cache hit/miss/error dashboards for unexpected variation in cached responses across identical requests
- Flag unusual or unrecognized headers (e.g., X-Forwarded-Host, X-Original-URL) in incoming traffic before they can influence a cached response
- Audit cache access logs for anomalous cache keys or repeated probing patterns
- Use automated scanners (e.g., Param Miner) to identify unkeyed inputs that influence responses
- Watch status-code distribution dashboards (2xx–5xx breakdown) for sudden spikes in cached error pages, paired with log review for injected script content
|
- Define an explicit, custom cache key that includes the headers, query strings, and cookies that affect the response
- Normalize and validate headers at the edge, before they ever reach the origin server
- Apply a no-cache policy to any path that reflects user input, so those endpoints stay uncached unless the input is rigorously sanitized
- Apply strict input validation and output encoding on any header or parameter used in responses
- Send Cache-Control: no-store or private from the origin for dynamic or user-specific content and confirm the CDN honors these origin directives or disable caching outright at the path level
|
| Web Cache Deception |
- Detect mismatches between requested URL paths and the resource type actually served, this check sits at the origin/application layer, since routing and content-type decisions happen outside the CDN
- Monitor for crafted requests that append static-looking extensions (e.g., .css, .js) to dynamic or authenticated paths
- Review cache access logs for sensitive or personalized pages being served from cache to anonymous users
- Test authenticated endpoints with path confusion payloads to confirm safe caching behavior
- Track unusual access patterns to cached URLs containing session-specific data via cache access logs
|
- Ensure the cache keys on the full URL path by default, not just file extension or static-looking suffixes
- Explicitly exclude authenticated and personalized routes from caching by default, using a dedicated no-cache rule per path
- Ensure the origin server, not just the CDN layer, enforces correct content-type and routing logic, this remains the application team's responsibility
- Normalize URL paths server-side before cache lookup to eliminate path confusion
- Apply Cache-Control: private or no-store headers on sensitive, user-specific responses, and confirm the CDN respects them, reinforced with a no-cache rule on those paths for defense-in-depth
|
How Radware CDN Strengthens Cache-Layer Security
Radware approach to cache security focuses on making performance and security controls work together at the delivery layer, rather than treating cache protection as an isolated CDN configuration task.
Cache-aware delivery controls: Radware CDN provides control over how content is cached and delivered, allowing organizations to define caching behavior based on application requirements rather than relying solely on default caching behavior. Proper control of cache keys, cacheable content and origin cache directives helps ensure that responses are not incorrectly shared or stored.
Alignment between CDN and origin behavior: Cache security depends on maintaining consistency between what the CDN caches and how the origin application processes request. Radware CDN allows caching behavior to be explicitly configured for application delivery requirements, helping reduce the risk of situations where the CDN treats requests as equivalent while the origin treats them differently.
Operational consistency: Radware provides unified management and reporting across its delivery and security capabilities, along with a single SSL key shared across CDN and protection services. This allows caching, delivery, and security controls to be managed within the same operational framework, reducing independent configurations and helping minimize configuration drift. Where additional application protection is required, security capabilities can operate alongside the CDN without separating security from the traffic delivery layer.
Takeaway
Web cache poisoning and web cache deception demonstrate that performance and security cannot be treated as separate concerns. Protecting modern applications requires more than correct cache configuration, it demands that caching and security policies work together throughout the request lifecycle. By integrating CDN, WAF and centralized visibility into a single platform, Radware CDN helps organizations reduce operational complexity while delivering both high-performance content delivery and stronger protection against evolving cache-layer threats.
Interested in Radware's Application Security Solution?
Let Radware CDN help you safeguard applications, reduce cache-layer blind spots and deliver high-performance digital experiences with integrated application security.