Cache Key Scope and Data Leakage

Cache key scope is one of the most important security boundaries in a caching system. If the key does not include every dimension that changes the correct answer, one request can reuse another request’s cached result incorrectly. When that missing dimension is user, tenant, locale, authorization scope, or policy context, the result is not just stale data. It is data leakage.

Teams often treat key design as a performance detail. It is not. The key defines identity. If identity is incomplete, the cache may confidently serve the wrong user’s or wrong tenant’s data with perfect speed.

    flowchart LR
	    A["Request: /account"] --> B["Key built only from path"]
	    B --> C["cache key = page:/account"]
	    C --> D["Shared cache returns response for previous user"]
	    D --> E["Confidential data leaked"]

Why It Matters

The most dangerous cache bugs are often not about expiration. They are about scope. A cache that serves old public data is annoying. A cache that serves another user’s private data is a security incident.

Scope mistakes usually happen when:

• the key ignores user or tenant identity
• the key ignores request dimensions controlled by Vary-style semantics
• a layer assumes content is public when it is actually session-bound
• the team reuses public-cache patterns on semi-private data

What Belongs in Identity

Not every request attribute belongs in the key, but every attribute that changes the meaning or visibility of the answer must be reflected somehow.

That may include:

• user ID or tenant ID
• region or locale
• role or permission bucket
• feature flag or audience segment
• content negotiation dimensions such as language or compression

1safe_key_dimensions:
2  account_overview:
3    - user_id
4    - tenant_id
5    - locale
6  public_product_page:
7    - product_id
8    - locale
9    - currency

Example

This example contrasts an unsafe shared key with a safer scoped one.

1function unsafeKey(path: string) {
2  return `page:${path}`;
3}
4
5function saferAccountKey(path: string, tenantId: string, userId: string, locale: string) {
6  return `page:${path}:tenant:${tenantId}:user:${userId}:locale:${locale}`;
7}

What to notice:

• the unsafe key is attractive because it maximizes reuse
• the safer key reduces reuse, but it preserves confidentiality
• cache efficiency is not worth a scope violation

Common Mistakes

• assuming path alone determines response identity
• forgetting that personalization can exist even when the route looks generic
• caching mixed public and private data under the same family without explicit separation
• relying on application code to filter data after a shared cache already returned the wrong payload

Design Review Question

How do you decide whether a request attribute should be part of cache identity or not?

The stronger answer is that an attribute belongs in identity whenever changing it can change the content, visibility, or policy of the response. If leaving the attribute out could let one actor see data intended for another, it is part of the security boundary and must be modeled explicitly.

Quiz Time