Cache Buster

What a cache buster changes in testing

A cache buster changes the request enough that intermediaries treat it as a fresh lookup instead of a replay of an older response. In security testing, that lets you separate genuine application behaviour from cached behaviour, which is essential when you are trying to see whether the server is reflecting untrusted input or whether a proxy is reusing content.

Why cache busting matters for poisoning tests

Cache poisoning is only visible when the tester can reliably force a new fetch or a distinct cache key. Without that, you can get false confidence from a response that looks safe only because it came from cache. A cache buster helps expose whether a response varies by request details, headers, or routing decisions that a cache might otherwise obscure.

That distinction matters because poisoning often depends on the gap between origin behaviour and cached behaviour. If one request path populates a cache entry and another path or header combination is later served from that entry, the tester needs to know which inputs actually influence the stored response and which are ignored.

How cache busters are used in practice

Typical cache busting adds a unique query parameter, path element, or other benign change that should not alter the business meaning of the request. The goal is not to evade controls, but to create a clean test condition. Good use of a cache buster preserves the response semantics while breaking accidental reuse from browsers, reverse proxies, CDNs, or application caches.

Practitioners should treat the technique as a measurement aid, not a fix. If a response only becomes visible after cache busting, that can indicate a cache-control problem, a keying problem, or a response variance issue, but it does not by itself prove exploitable poisoning.

What a cache buster can and cannot tell you

A cache buster is useful for confirming freshness, but it does not prove the absence of caching. A response may still be cached on different dimensions such as host, scheme, path, header set, or user context. It also does not tell you whether the cache is correctly separating personalised content from public content, only that the specific test request was treated as unique.

For that reason, cache-busting tests are usually paired with repeated requests, controlled header variation, and comparisons between origin-facing and cache-facing behaviour. The value is in revealing whether the application and cache layers agree on what makes a request unique.

Risk and Threat Considerations

Cache poisoning risk arises when a cache stores a response that should have been limited to a specific request context and then serves it to other users. That can lead to incorrect content delivery, security header confusion, reflected payload persistence, or broader trust failures in front of the application.

Failure mechanism: An attacker or tester finds a request component that influences the origin response but is not handled safely by the cache key, then causes that response to be stored and replayed for later requests.

Impact: Users may receive poisoned content, misleading security controls, or attacker-influenced application output, and the real issue can remain hidden until a fresh request bypasses the cache.

Practitioner Guidance

What to watch for: Use cache-busting deliberately when you need to distinguish origin behaviour from cached behaviour, but always pair it with an inventory of the caching layers in front of the target. If the same endpoint behaves differently only when a request is made unique, that is a signal to investigate cache key design, variation rules, and response caching policy.

Practitioner takeaway: Cache busting is a diagnostic technique, not a remediation. If a response is unsafe when uncached, the underlying cache policy and response handling still need to be corrected.

Related resources from NHI Mgmt Group

• What is the difference between request-scoped caching and a shared application cache?
• Why can file-integrity checks miss page-cache corruption exploits?
• How should security teams distinguish DNS cache problems from identity access failures?
• When should teams clear DNS cache during incident response?