An unkeyed input is any request value that affects the server response but is not included in the cache key. Common examples are custom headers, cookies, or routing hints. These inputs are dangerous because a cache may store a response generated from attacker-controlled data and then serve it to other users.
Expanded Definition
Unkeyed input refers to request data that influences how a server responds but is not part of the cache key. That distinction matters because a cache can treat two requests as equivalent even when the origin server produced different content for each one. In practice, the input is often carried in custom headers, cookies, forwarding headers, or routing hints that alter language selection, device targeting, or backend behaviour.
For security teams, the term is most often discussed in web application and edge caching contexts, where response reuse can create cross-user exposure. The risk is not that the input is inherently malicious, but that the cache does not vary on it, allowing attacker-influenced content to be reused by other visitors. Guidance varies across vendors on how broadly the term should be applied, but the core idea is stable: if a request value changes the response, it must be considered in cache behaviour or excluded from cacheable paths.
The most common misapplication is assuming all response-shaping inputs are automatically keyed, which occurs when developers trust default cache settings without testing how headers and cookies affect the returned content.
Examples and Use Cases
Implementing cache controls rigorously often introduces more origin traffic and more configuration complexity, requiring organisations to weigh performance gains against the risk of serving attacker-influenced content.
- A site uses a
cookie to select a user theme, but the CDN cache key does not include that cookie, so one user’s personalised page can be served to another.
- A reverse proxy reads a custom header to decide whether to show mobile or desktop markup, yet the cache ignores that header and stores only one variant.
- An application varies its response based on a routing hint or geolocation header, but the edge cache treats the response as universal.
- Security testers probe for cache poisoning by sending unusual request values and checking whether downstream users receive a cached variant built from those values.
- Teams review caching behaviour alongside the broader guidance in the NIST Cybersecurity Framework 2.0 to validate that web controls are monitored and consistently maintained.
Why It Matters for Security Teams
Unkeyed input is a practical security concern because it can turn a benign cache into a delivery path for poisoned or misleading content. The issue often appears at the boundary between application logic and infrastructure controls, where developers assume the cache understands every response-affecting signal while operations teams assume the application is cache-safe. That gap can produce integrity failures, session confusion, and hard-to-trace user impact.
For defenders, the priority is to identify which request values influence response generation, then ensure cache keys, cache bypass rules, or response headers account for them. This is especially important on shared front ends, multi-tenant platforms, and content delivery layers where one bad variant can reach many users. In identity-adjacent flows, unkeyed input can also affect authenticated views, making cache behaviour part of the access-control surface rather than a pure performance concern.
Organisations typically encounter the consequences only after users report inconsistent pages or security tests show one request altering many others, at which point unkeyed input 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.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-5 | Cache integrity and data handling are relevant when unkeyed input can poison shared responses. |
| NIST SP 800-53 Rev 5 | SC-5 | Cache misuse creates denial and integrity risks that align with boundary and flow protection concerns. |
| ISO/IEC 27001:2022 | A.8.9 | Configuration management applies to cache rules and response variation settings touched by this term. |
| OWASP Non-Human Identity Top 10 | Shared response paths can expose identity context when cookies or headers are not keyed. | |
| NIST SP 800-63 | AAL2 | If unkeyed input affects authenticated views, assurance depends on stable session handling. |
Treat cache-key coverage as an integrity control and verify response variation is safe before deployment.
Related resources from NHI Mgmt Group
- What is the difference between application input validation and identity control?
- What is the difference between LDAP injection and ordinary input validation bugs?
- What is the difference between input sanitization and blast-radius control?
- What breaks when a password reset flow trusts attacker-controlled input?
