Cache Key Collision

How cache key collisions happen

cache key collision occurs when a cache key is built from too little request detail, so two distinct requests normalize to the same stored entry. The result is not a simple miss, but an ambiguous match that can return the wrong object or response.

This usually reflects a design problem in the cache key formula, not a bug in caching itself. If URL, query parameters, headers, host, method, or tenant context are omitted or reduced too aggressively, the cache may treat distinct content as interchangeable.

The issue matters most in shared caches, including application caches, CDNs, and reverse proxies, where one key can be reused across many users or tenants. A collision can therefore propagate stale, private, or attacker-influenced content far beyond the original request.

A useful way to think about the problem is that the cache is faithfully doing what the key tells it to do, even when the key is incomplete. That makes key design a security boundary, not just a performance detail.

Why collisions create security exposure

When two different requests collapse onto the same key, the cache can serve content that belongs to the wrong request context. That can expose personalised data, authenticated views, locale-specific responses, or tenant-specific content if the key does not preserve the full context that shapes the response.

Cache key collisions also undermine cache integrity. An attacker who can influence one request variant may be able to poison the shared entry and cause other users to receive content chosen by the attacker, especially when caches trust normalized inputs too much.

Because the problem sits at the intersection of correctness and trust, it can be difficult to spot during normal testing. The response still looks valid, but it may belong to the wrong cache population, which makes the failure easy to miss and hard to attribute.

For broader guidance on cache key design, unkeyed inputs, and safe cache-control rules, see Web Cache Poisoning and Cache Deception Guide.

Where collisions typically come from

Collisions usually appear when caches normalize too aggressively or ignore inputs that materially affect the response. Common causes include stripping query strings, collapsing header values, failing to vary on host or device context, or reusing the same key across authenticated and unauthenticated traffic.

Multi-tenant systems are especially exposed when the cache key does not carry tenant identity or equivalent isolation context. In that case, distinct tenants can map to the same cached representation even when the application intends them to remain separate. The Multi-Tenant SaaS Authorisation and Tenant Isolation Guide is relevant when cache keys need to preserve tenant boundaries and avoid cross-tenant leakage.

Reverse proxies and CDNs add another layer of complexity because the application may believe one set of inputs matters, while the edge cache uses another. If those layers do not agree on what constitutes a unique response, collisions and cache confusion become much more likely.

How organisations prevent and verify it

Prevention starts with defining the response dimensions that must be part of the cache key, then validating that the implementation matches that definition. Teams should confirm the cache key against actual request variation, not just against the developer’s assumptions about which inputs are “usually” safe to omit.

Verification should include asset inventory for every cache layer, review of vendor and CDN cache policies, and testing for unkeyed inputs or overly broad normalization. Where responses differ by user, tenant, authentication state, language, device, or other security-relevant context, the key should preserve that distinction.

When exposure is uncertain, treat cache key design as part of secure architecture review rather than an optimisation afterthought. The most reliable cache is one whose key structure is explicit, documented, and tested against the response variants the system actually produces.

For a broader control perspective on access control, identification, and secure configuration, practitioners often map these issues to NIST SP 800-53 Rev 5 Security and Privacy Controls and to the HTTP caching guidance in NIST Cybersecurity Framework 2.0.

Risk and Threat Considerations

Cache key collisions can turn a performance control into a data exposure path when different users, tenants, or request states are forced through the same cached object. The risk is highest where cached content is personalized, authorization-sensitive, or influenced by attacker-controlled inputs.

Failure mechanism: A cache key that omits a material request dimension allows one response to overwrite another or be replayed in the wrong context, creating cache poisoning, data leakage, or cross-context confusion.

Impact: Users may receive stale, private, or attacker-shaped responses, and defenders may struggle to detect the issue because the cache appears to be functioning normally.

Practitioner Guidance

What to watch for: Treat collisions as a design-review and testing problem, not only an incident-response problem. Pay special attention to caches that sit in front of authenticated flows, tenant-aware applications, or any system where response content varies by header, cookie, host, or parameter.

Governance implication: Cache key rules should be owned like other security-relevant architecture decisions, with explicit review when response variation changes. If a response can differ in a way that matters to confidentiality or isolation, the cache key should preserve that difference.

Related resources from NHI Mgmt Group

• How should security teams test whether a cache key is safe from poisoning in practice?
• Why do small cache key transformation bugs create outsized risk for web applications?
• What do teams get wrong about detecting cache poisoning and related cache key flaws?
• What are the signs that cache key normalization is failing in a web application?