Cache-busting bots create request variations that may prevent a cache from reusing an existing response. Investigate them by comparing request variants, cache outcomes, and the work reaching the origin.
Start with the actual cache key. Different URLs do not necessarily mean different cache entries in every deployment, and a low hit rate does not automatically mean an attack.
AWS describes query-string variation as a mechanism in cache-busting HTTP floods. Legitimate asset versioning and application filters also vary URLs, so the mechanism alone does not establish intent.
Choose one route and reconstruct its cache policy
Record the route, cache layer, relevant request parameters, response directives, and whether content differs by account, language, or another context. Include recent cache and application changes.
Do not begin by removing every query parameter from the key. RFC 9111 describes cache selection using the target URI and relevant variation. Reusing the wrong response can create a correctness or data-exposure problem.
Confirm whether the response is eligible for shared caching at all. A personalized result may appropriately miss a shared cache even when the request rate is high.
Compare variants with the origin work they create
Group a bounded sample by normalized route and parameter names. Keep sensitive parameter values out of ordinary reports. Compare distinct variants, cache outcomes, origin requests, and origin execution time.
A global cache-hit percentage can hide a small, expensive route. Review that route's request volume and work separately from static assets.
| Observation | Question to answer |
|---|---|
| Many unique values for an unfamiliar parameter | Does the application use it, ignore it, or reject it? |
| Hit rate falls after a release | Did the cache key or response policy change? |
| Origin work rises without more edge requests | Did request cost or cache eligibility change? |
| One account receives private responses | Is bypassing shared cache intentional? |
| New versioned asset URLs appear | Does the pattern match a normal deployment? |
Preserve alternative explanations until the application and caching owners have checked them.
Classify parameters before normalizing anything
Consider a hypothetical result endpoint with a language parameter, a filter parameter, and an unrelated tracking parameter. The first two may change the response. The third might not.
That is a hypothesis to verify against the implementation. Compare responses under controlled conditions, including authentication and locale. A parameter ignored by one handler may affect another handler or a downstream service.
If the team chooses to exclude a parameter from the key, document why doing so preserves response meaning. Prefer an explicit, reviewed allowlist of meaningful variation over a broad emergency transformation.
Also inspect unknown-parameter handling. Rejecting unsupported input may be clearer than accepting unlimited variants whose behavior nobody owns.
Apply protection before unnecessary origin work
Where your architecture supports it, enforce route-specific request or work budgets before forwarding expensive requests. Keep approved crawlers and client integrations within documented allowances.
If a rule is enforced after the origin has generated the response, it may change what the requester receives without relieving the origin. Check the request path, not just the presence of a block event.
Avoid making private responses public as a performance fix. If a route cannot safely use shared caching, its capacity and admission controls need to reflect that.
Verify both load and response correctness
After a change, compare cache reuse and origin work for the selected route. Check that language, filters, authentication, and error responses still behave correctly. Include an ordinary deployment's versioned assets in the review.
Record the previous cache configuration and a rollback owner. Cache changes can affect many users even when the initial investigation concerns one suspected client.
Use the layer 7 response guide if overload is active. For broader protection scope, see the traffic flood use case. Bring the reviewed cache key and one origin-work comparison; those are more useful than a list of suspicious query strings.