Cybersecurity glossary
What is a Cache Key?
Learn what a cache key is, which request attributes shape it, how Vary and normalization affect cache hits, and why weak key design causes collisions, leaks, and poisoning.
Definition
A cache key is the identifier an HTTP cache uses to decide whether a stored response matches a new request, typically derived from the request method, target URI, and selected headers named in Vary, so that different representations are not served from the same slot.
Why cache keys matter
Every cache is a map from “this request” to “that response.” The cache key is how the map is indexed. When the key is too coarse, unrelated requests collide. When it is too fine, nothing hits and performance gains disappear.
For security-aware teams, cache keys are not an implementation detail—they decide whether a CDN might serve one visitor’s session-specific HTML to another, or whether a poisoned error page propagates widely under a single label.
How cache keys are formed
Caches derive keys from stable request attributes and from Vary on the stored response. The exact normalization rules differ between browser caches, reverse proxies, and commercial CDNs, which is why behavior must be verified—not assumed from RFC text alone.
Collect request inputs
Method, authority, path, query, and optionally selected headers enter the keying function.
Apply normalization rules
Hosts may fold case, sort query parameters, or strip fragments according to cache implementation.
Merge Vary dimensions
For each header named in Vary on a candidate entry, the cache compares request header values.
Lookup or miss
A matching key with a fresh, storable response yields a hit; otherwise the origin is contacted.
Store with metadata
On miss, the response is saved under the computed key along with freshness and Vary data.
Key ingredients teams control
Method and URL
The baseline identity of a resource. GET and HEAD are cacheable; unsafe methods usually are not.
Query strings
Parameters often differentiate representations. Some CDNs can ignore them—know your edge policy.
Vary headers
Accept, Accept-Encoding, Accept-Language, and Authorization commonly partition keys.
Scheme and host
http and https, or www and apex, must not collide unless you deliberately unify them.
Cookies and auth
Personalized responses usually must not share keys with anonymous traffic.
CDN custom rules
Edge platforms may add or remove key parts independent of browser behavior.
Cache key design patterns
| Scenario | Typical key includes | Risk if wrong |
|---|---|---|
| Fingerprinted static asset | URL path only (hash in filename) | Low; representation is immutable per URL |
| Compressed JSON API | URL + Vary: Accept-Encoding | Serving gzip body to a client that cannot decode |
| Localized marketing page | URL + Vary: Accept-Language | Wrong language shown from shared cache |
| Authenticated dashboard HTML | Should not be in shared cache | Cross-user data exposure under one key |
| A/B test via query param | URL including variant query | Users see the wrong experiment arm |
Design checklist
- List every axis that changes the response body or critical headers (locale, encoding, auth, experiments).
- Emit accurate Vary for negotiated dimensions; do not rely on implicit browser behavior.
- Keep personalized HTML and APIs out of shared caches or key them so broadly that hits are impossible.
- Document CDN cache-key overrides and test them with representative requests.
- Treat unexpected cache hits on dynamic routes as potential keying bugs, not free performance.
- Normalize URLs at the origin consistently so keys do not fragment for the same resource.
- Review error and redirect responses; poisoned entries often enter through unkeyed variance.
- Pair key design with Cache-Control privacy directives for defense in depth.
Limits and pitfalls
RFCs describe ideal cache behavior, but production stacks combine browser heuristics, corporate proxies, and vendor-specific edge logic. A key that works in Chrome DevTools may still collide at the CDN if cookies are stripped from the key while responses remain user-specific.
Another pitfall is over-keying: including volatile headers like User-Agent in Vary can destroy hit rates without improving correctness. The goal is to include every dimension that changes semantics—not every header that ever appears on a request.
The practical takeaway
Cache Key design decides which requests are considered equivalent for reuse. Treat it as part of your threat model: if two requests can receive different security-sensitive bytes, they must not share a key in a shared cache.
Document keying at the CDN, validate Vary against real content negotiation, and prefer narrow public caching for immutable assets over heroic key gymnastics on dynamic HTML.
Related security terms
Cache-Control
Directives that decide whether a response may be stored under a key at all.
Cache Revalidation
How caches confirm a keyed entry is still valid before reuse.
Web Cache Poisoning
Attacks that exploit shared caches when keys omit important request variance.
Content Negotiation
How servers pick representations that must be reflected in cache keys via Vary.
Frequently asked questions
What is a cache key in simple terms?
It is the label a cache uses to remember a response. When a new request arrives, the cache computes the same label. If it matches a stored entry and freshness rules allow, the cache can reuse that response.
What is usually part of an HTTP cache key?
Most caches start with the request method and URL. They may also include query strings, scheme, host, and any headers listed in the response Vary field, such as Accept-Encoding or Accept-Language.
Why does Vary matter for cache keys?
Vary tells caches which request headers changed the response. If the server sends different bodies for different Accept values but forgets Vary, two clients can receive the wrong representation from one key.
Can two different users share the same cache key?
Yes, and that is often intentional for public assets. For personalized HTML or APIs, sharing a key is dangerous unless the response is identical for every user who would hit that key.
Do CDNs always use the same cache key as browsers?
No. CDNs let operators customize keys, sometimes ignoring cookies or query parameters that browsers would treat as distinct. Misconfiguration can create hits where misses were expected—or leaks where hits should never occur.
How do cache keys relate to cache poisoning?
If a cache key ignores headers or parameters that actually change the response, an attacker can seed a harmful response that later serves to innocent visitors under the same key.
References
Explore authoritative guidance and frameworks related to cache key.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.