Join our Newsletter — 33% off our NHI Course

Cache Flooding

Cache flooding is an attack that overwhelms a cache with enough requests or distinct entries to evict useful data. The attacker forces repeated misses and extra backend lookups, increasing latency and load on the origin service or network device.

How Cache Flooding Works

Cache flooding is a denial pattern that targets the cache itself, not just the origin service behind it. By forcing a high rate of requests or a large variety of entries, the attacker reduces cache hit rates and turns the cache into a constant source of misses.

The key effect is eviction pressure. Useful objects are pushed out before they can be reused, so the system spends more time rebuilding state, fetching from origin, or recomputing responses that should have been served quickly.

Why Cache Flooding Degrades Performance

Cache flooding hurts both latency and throughput. When the cache stops absorbing repeated lookups, backend systems take the extra load, which can increase queueing, saturate shared resources, and amplify response times across an application or network path.

The attack is especially disruptive when the cache protects a hot set of data that many users share. Even if the origin is healthy, the loss of cache efficiency can make a normally fast service feel unstable, because every miss reintroduces work that the cache was meant to suppress.

Common Cache Flooding Conditions

Cache flooding becomes more effective when the cache key space is easy to vary, object lifetimes are short, or cache size is limited relative to request diversity. Attackers can exploit these conditions with randomised parameters, high-cardinality inputs, or carefully chosen request patterns that look like legitimate traffic.

Any design that allows unbounded variation in cache keys is a risk multiplier. If each new key can evict a useful object, the defender is effectively giving the attacker a way to trade cheap requests for expensive backend work.

Detecting and Limiting Cache Flooding

Detection usually starts with observing hit-rate collapse, unusual miss bursts, rising backend fetch volume, or request patterns that generate many unique keys without corresponding reuse. These signals matter because the cache can appear “busy” while actually delivering little value.

Defence is about making eviction harder to abuse and making misses cheaper to survive. Rate limiting, request normalisation, tighter cache key design, object eviction controls, and backend protection all help reduce the damage when a flood begins.

Risk and Threat Considerations

Cache flooding can become a practical denial-of-service vector because it shifts pressure from the cache layer to the origin. That makes it attractive in front of expensive application services, shared network devices, or multi-tenant environments where a local cache protects many users at once.

Failure mechanism: The attacker creates enough cache churn that useful entries are evicted before reuse, driving repeated misses, extra backend lookups, and sustained load amplification.

Impact: Users see slower responses, origin capacity is consumed by avoidable work, and collateral service degradation can spread beyond the targeted endpoint if shared infrastructure is exhausted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 DE.CM-01 — Continuous Monitoring Cache hit-rate collapse and miss spikes are operational signals to monitor.
PR.DS-01 — Data-at-Rest Cache entries are stored responses whose lifecycle and exposure affect service efficiency.
PR.PS-04 — System Changes Are Controlled Cache-key design and eviction behaviour must be controlled to prevent abuse.
Recommendation — Monitor cache hit ratio and backend amplification for early signs of flooding. Protect cached data with bounded retention and eviction policies. Constrain cache-key variation and control changes to caching logic.
CIS Controls v8 CIS-12 — Network Infrastructure Management Cache flooding can target shared network and edge infrastructure that depends on caching behavior.
CIS-13 — Network Monitoring and Defense Detection depends on identifying unusual miss rates and request patterns.
Recommendation — Tune and harden caching infrastructure to limit abuse-driven load amplification. Alert on abnormal miss bursts, eviction pressure, and backend read surges.

Practitioner Guidance

What to watch for: Treat sudden drops in cache hit ratio, spikes in unique-key traffic, and backend read amplification as early warning signs. Those patterns often appear before full user-visible outage, which gives defenders time to reduce the blast radius.

Governance implication: Cache design should be reviewed as a resilience control, not only as a performance optimisation. Teams should decide which responses are safe to cache, how cache keys are formed, and what load-shedding behaviour protects the origin when the cache is under stress.