Vary: * is a special HTTP response directive that tells caches the response depends on factors that cannot be represented as ordinary request headers. It is meant to prevent unsafe reuse. If cache handling is wrong, the response can still be stored and served outside the intended context.
Expanded Definition
NIST Cybersecurity Framework 2.0 is not the source of the term itself, but it is a useful governance lens for understanding why response caching controls matter. Vary: * is a special HTTP response directive used when a server response is context-sensitive in ways that normal request header variations do not capture. It signals that reuse of the cached response is unsafe unless the cache can reliably preserve the intended conditions.
In practice, the directive is associated with edge cases where developers or intermediaries try to force a response to be cached despite missing a precise vary key. That is where definitions vary across vendors and implementations: some caches treat the directive as a strict prohibition on reuse, while others may still store the object and later mis-serve it if policy logic is incomplete. For security teams, the important distinction is not whether the response is cacheable in theory, but whether the cache can prove the same security context still applies.
The most common misapplication is treating Vary: * as a generic optimisation flag, which occurs when teams assume it only affects performance rather than cache safety.
Examples and Use Cases
Implementing cache directives rigorously often introduces complexity at the CDN, reverse proxy, and application layers, requiring organisations to weigh performance gains against the risk of serving a response in the wrong context.
- A login-related endpoint returns personalised content and should not be reused across users, so the cache policy must prevent broad replay of the response.
- An application varies output by an internal decision that is not exposed as a standard request header, making safe caching difficult without explicit cache controls.
- A reverse proxy fronts an API that behaves differently under authentication changes, and the cache key must not collapse distinct security states into one object.
- A developer references HTTP caching guidance from the NIST Cybersecurity Framework 2.0 style of risk thinking to ensure caching decisions do not undermine integrity or confidentiality.
- A shared caching layer stores a response that was intended only for a specific downstream context, exposing the danger of unsafe reuse when cache logic is too permissive.
These examples show that the directive is most relevant when response behaviour is conditional but not easily expressed through ordinary cache variation rules. It is especially important in web applications with intermediaries, authentication boundaries, or mixed public and private responses.
Why It Matters for Security Teams
Security teams care about Vary: * because cache misconfiguration can create disclosure, integrity, and session boundary problems that are hard to detect during normal testing. A response that is safe for one user, one device state, or one downstream context can become unsafe if a shared cache reuses it incorrectly. That makes the directive relevant to web application security, platform engineering, and incident response.
For governance, the key issue is whether teams understand when caching is being used as an infrastructure optimisation versus when it becomes part of the security boundary. If the response depends on conditions that a cache cannot faithfully encode, the safer design is often to prevent reuse rather than rely on implicit behaviour. This is consistent with broader secure delivery principles found in NIST Cybersecurity Framework 2.0, where protecting data in transit and at rest includes controlling how intermediaries handle sensitive content.
Organisations typically encounter the impact only after a stale or context-inappropriate response is exposed to the wrong requester, at which point Vary: * becomes operationally unavoidable to address.
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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Cache safety affects how sensitive data is protected when intermediaries reuse responses. |
| NIST SP 800-53 Rev 5 | SC-13 | Cryptographic and transport safeguards often sit alongside cache handling for sensitive responses. |
| ISO/IEC 27001:2022 | A.8.12 | Information leakage through shared caches maps to controls for data leakage prevention. |
Treat unsafe cache reuse as a data protection issue and block response sharing across security contexts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
