Web Cache Poisoning: Causes, Tests, and Prevention

Web cache poisoning occurs when an attacker influences a response that a shared cache stores and later serves to other users. The request component controlling the response may be absent from the cache key, allowing one crafted request to affect many ordinary visitors. The result can range from broken pages to injected redirects or scripts.

The defense is to align cache keys with every input that changes a cacheable representation, reject ambiguous requests, and avoid caching responses affected by untrusted values. Origin and CDN behavior must be tested together.

What the topic means

A cache key usually includes scheme, hostname, path, and selected query parameters or headers. An unkeyed input is a request value that changes the response but is not included in the key. Forwarded hosts, alternate routing headers, query normalization, cookies, and content-negotiation headers are common places for dangerous mismatches.

Core principles

Validate the canonical host

Accept only configured hostnames and generate absolute URLs from trusted configuration rather than arbitrary request headers.

Trust forwarded headers narrowly

Honor proxy headers only from known infrastructure and overwrite client-supplied values at the edge.

Keep cache variation explicit

If a request value changes output, include it in the key, normalize it safely, or make the response uncacheable.

Separate personalized content

Authenticated and user-specific responses should not share public cache entries unless a carefully designed surrogate layer removes variation.

Step-by-step workflow

1. Map the cache path. Document browser, CDN, reverse proxy, framework, application, and upstream caches plus the key and policy at each layer.
2. Enumerate response inputs. Test host, forwarding headers, path encoding, query parameters, method overrides, language, compression, cookies, and custom routing headers.
3. Use harmless markers. In an authorized environment, send unique safe values and check whether they influence a response later served to a normal request.
4. Fix the mismatch. Reject the input, derive values from configuration, add required key variation, normalize consistently, or disable caching for that route.
5. Purge affected entries. Invalidate poisoned objects using exact keys and variants, then confirm clean responses from multiple locations.
6. Add regression tests. Cover alternate encodings, duplicate headers, query order, redirects, error pages, and direct-origin access after every cache change.

Practical example

A site builds password-reset links from an unvalidated forwarded host. The CDN cache key uses the public hostname but the origin trusts the attacker’s header, so a crafted response can contain a malicious domain. The edge strips client forwarding headers, the application uses configured origin data, and the affected cache entries are purged.

How to test the control

Test this workflow in a controlled environment before relying on it in production. Begin with “Map the cache path” and create three cases: an expected success, a safe rejection, and a degraded or unavailable dependency. Continue through “Enumerate response inputs” and “Use harmless markers,” recording timestamps, identifiers, logs, and the operator decision. Repeat the exercise after meaningful changes to providers, permissions, dependencies, or architecture. A control is operational only when another team member can follow the documented process and obtain the expected result without hidden knowledge.

Metrics and review cadence

Measure completion and outcome separately. For this topic, track evidence that “Cache layers and keys are documented,” “Canonical hosts are allowlisted,” and “Forwarded headers come only from trusted proxies” remain true, then pair those checks with operational signals such as unexpected changes, denied actions, stale ownership, error volume, recovery time, or unreviewed exceptions as appropriate. Review trends rather than celebrating a single pass. A growing exception count may show the workflow is too difficult, while zero alerts may mean the detection path is not functioning.

Operating this in production

Performance controls sit on a trust boundary because proxies and browsers reuse responses. Cache behavior must be explicit, testable, and aligned with authentication and content variation. Faster delivery is valuable only when the correct user receives the correct representation. Review the workflow after incidents, major releases, access changes, and meaningful growth. Assign an owner and keep evidence that the control works instead of recording only that it exists.

Common mistakes

• Testing only the origin without the CDN.
• Adding every header to the key and destroying cache efficiency.
• Trusting forwarding headers from direct internet traffic.
• Caching redirects generated from request input.
• Purging one URL while leaving encoded variants.

Duck Cloud tools for the workflow

Use the HTTP Header Checker to inspect cache and proxy headers, the Redirect Checker for cached location changes, the URL Decoder to inspect encoded paths and queries, and the Website Status Checker for authorized external verification.

Review checklist

• [ ] Cache layers and keys are documented
• [ ] Canonical hosts are allowlisted
• [ ] Forwarded headers come only from trusted proxies
• [ ] Response-changing inputs are keyed or rejected
• [ ] Personalized content is isolated
• [ ] Encoded and duplicate inputs are tested
• [ ] Purge procedures cover variants
• [ ] Regression tests run after proxy changes

Conclusion

Web Cache Poisoning becomes valuable when it is repeatable, owned, and verified. Start with the highest-impact boundary, document the expected state, test realistic failure cases, and fix the gaps that evidence reveals. Small controls maintained consistently are more reliable than a large policy that nobody exercises.