CDN Poisoning Attacks: How Cached Content Becomes a Weapon

Your CDN Is a Supply Chain Component

Content Delivery Networks are ubiquitous in modern web architecture. Cloudflare, Fastly, Akamai, CloudFront, and similar services cache and serve your content from edge locations worldwide, reducing latency and offloading traffic from origin servers.

CDNs are also supply chain components that sit between your application and every user. When a CDN serves cached content, users trust that the content is identical to what your origin server would return. Cache poisoning attacks exploit this trust by tricking the CDN into caching and serving malicious content.

The impact is severe. Unlike a typical web attack that targets individual users through phishing or session hijacking, a successful cache poisoning attack serves malicious content to every user who requests the cached resource. The blast radius is the entire user base of the affected endpoint.

How Cache Poisoning Works

Cache poisoning exploits the gap between what the CDN uses as a cache key and what the origin server uses to generate responses.

The Cache Key Concept

A CDN cache key typically includes the URL path, query parameters, and the Host header. When a request arrives with a matching cache key, the CDN serves the cached response without contacting the origin server.

But HTTP requests contain many more components than the cache key: other headers, cookies, and request metadata. If the origin server uses any of these non-keyed components to generate the response, an attacker can manipulate them to produce a malicious response that gets cached under a legitimate cache key.

Basic Attack Flow

1. Attacker identifies a request header that the origin server reflects in its response but that the CDN does not include in its cache key
2. Attacker sends a request with a malicious value in that header
3. Origin server generates a response that includes the malicious value (e.g., reflected in a script tag, a redirect URL, or an API response)
4. CDN caches this response under the normal cache key
5. Every subsequent user who requests the same URL receives the cached malicious response

Common Exploitable Headers

X-Forwarded-Host / X-Forwarded-Scheme: Applications that use these headers to generate URLs can be tricked into producing responses with attacker-controlled URLs. If the CDN does not include these headers in its cache key, the response with malicious URLs gets cached.

X-Original-URL / X-Rewrite-URL: Some frameworks use these headers for URL rewriting. An attacker can manipulate them to access different content than the URL suggests, potentially caching responses from restricted endpoints.

Accept-Language / Cookie variations: If the application varies its response based on language or cookie values but the CDN does not key on these, an attacker can poison the cache with a response targeted at a specific language or user state.

Real-World Impact

Cache poisoning has been demonstrated against major websites and applications:

JavaScript poisoning. If a cached JavaScript file is poisoned, the malicious code executes in every user's browser. This can enable widespread credential theft, session hijacking, or redirection to phishing sites.

API response poisoning. Poisoning cached API responses can manipulate application behavior for all users. In an e-commerce context, this could mean displaying wrong prices, redirecting payments, or exposing other users' data.

Denial of service. Poisoning a cache with error responses (by triggering error conditions on the origin) can cause the CDN to serve errors to all users for the duration of the cache TTL.

Prevention Strategies

Minimize Response Variation

The most effective defense is ensuring that your origin server does not use non-keyed request components to vary responses:

• Do not reflect request headers in responses unless absolutely necessary
• If you must vary responses based on headers, ensure those headers are included in the CDN cache key (using the Vary header)
• Remove unused framework features that process headers like X-Forwarded-Host or X-Original-URL

Proper Vary Header Usage

The HTTP Vary header tells CDNs which request headers affect the response. If your application varies responses based on Accept-Language, include Vary: Accept-Language in the response. The CDN should then include that header in its cache key.

However, overusing Vary reduces cache effectiveness. Each varied header multiplies the number of cached copies needed. Use Vary deliberately and only for headers that actually affect the response.

CDN Configuration

Strip unknown headers. Configure your CDN to strip headers that your application does not need before forwarding to the origin. If your application does not use X-Forwarded-Host, strip it at the CDN edge.

Cache key configuration. Some CDN providers allow explicit cache key configuration. Include any headers that affect response content in the cache key.

Cache TTL management. Shorter TTLs reduce the duration of a successful poisoning attack but increase origin load. Balance based on content sensitivity.

Content Security Policy

CSP headers can limit the damage from JavaScript poisoning:

• script-src restricts where scripts can load from
• connect-src limits where the application can make requests
• If a poisoned response includes a malicious script URL that violates CSP, the browser will block it

CSP is a defense-in-depth measure, not a primary defense against cache poisoning.

Monitoring

Monitor for cache poisoning indicators:

• Unexpected changes in cached response content or size
• Origin requests with unusual headers
• User reports of unexpected behavior that correlate with cache entries
• Anomalous cache hit rates (poisoning requires cache misses to inject malicious responses)

Supply Chain Dimension

CDN poisoning is a supply chain attack vector because the CDN is a distribution mechanism for your content. Just as a compromised package registry distributes malicious code, a poisoned CDN distributes malicious content. The mitigation principles are similar: verify integrity, limit trust, and monitor for anomalies.

How Safeguard.sh Helps

CDN configuration is part of your infrastructure supply chain. Safeguard tracks the components in your web infrastructure and monitors for vulnerabilities in the libraries and frameworks that generate responses your CDN caches. When a framework vulnerability enables cache poisoning — as several have in the past — Safeguard identifies affected applications and alerts your team before attackers exploit the gap.