A recently uncovered technique highlights how misconfigured web cache keys can become a serious security liability. Known as cache key injection, this tactic enables attackers to access restricted content, serve poisoned or malicious pages, or trigger denial of service—all without exploiting the usual unkeyed request values.
What’s happening under the hood
Web caching improves performance by storing server responses for repeated requests. Each cache entry is identified by a cache key, which is built using parts of the HTTP request—like scheme (HTTP or HTTPS), host, URI, accept headers, cookies, and more. The key issue arises when these elements are concatenated directly without boundaries, causing collisions where different requests map to the same cache key.
One proof of concept showed how combining a request for “/home” with an Accept header of “/” and another for “/h” with an Accept header of “ome*/*” could generate identical keys. As a result, a malicious actor could feed the cache one response and have it served to legitimate users requesting a different path.
Potential risks and scenarios
Cache key collisions put even protected endpoints at risk. For instance, an admin-only URL like “/admin” was exposed: although only localhost originally had access, an attacker managed to craft a distinct request that yielded the same cache key, effectively bypassing access controls.
Another serious concern is cache-poisoned denial of service (CPDoS). If an attacker’s request for a non-existent page (returning 404) collides with a valid page’s key, later visitors to the valid page might see the error page until the cache is cleared.
There’s also a risk of scheme confusion between HTTP and HTTPS. If a cache key includes the scheme without clear separators, an attacker might exploit the transition from HTTP to HTTPS. In one proof, abusing the Host header during HTTP requests produced the same cache key as equivalent HTTPS requests, enabling injection of attacker-controlled JavaScript via reflected Host values.
Even when using CDNs like Cloudflare in front of Nginx, risks remain. If edge caching is bypassed—for example by sending Authorization headers—but the origin server still caches the response, poisoned content may be cached at the origin. Later, once edge cache entries expire, poisoned data could be served to end users.
How to defend against caching attacks
The core mitigation is to stop concatenating raw fragments into cache keys without separators or structured encoding. Simply hashing ambiguous concatenations doesn’t solve the problem. Instead, configurations should use clear delimiters—such as pipes or other separators—between fields in cache key definitions.
Additionally, sensitive or access-controlled content should never be cached in shared caches. Also important: strict Host header validation, ensuring HTTP requests are redirected to HTTPS, and consistent cache behavior across all layers—from CDN to origin.
This issue isn’t about including user-controlled values in a cache key—it’s about how those fragments are combined. When boundaries are not enforced, attackers can craft collisions that turn caching, a performance feature, into a backdoor for exposure, defacement, or service disruption.
While the technical details are deep, the major lesson is simple: developers and ops teams must treat cache keys with the same security mindset applied to authentication and access control.
What’s next — what to watch
Security teams should immediately audit their web server configurations, especially Nginx setups where cache keys concatenate scheme, host, URI, and headers without clear separators. Any use of shared caching for authenticated content deserves scrutiny. Fixing HTTP-to-HTTPS behavior, adding strict validity checks for Host headers, and ensuring unified behavior between CDN and origin are straightforward mitigation steps.
With web cache poisoning tactics evolving, relying purely on response caching for performance without security-aware configuration is no longer acceptable. As attention grows around these vulnerabilities, this could reshape best practices for web performance, caching strategies, and secure design. Keep an eye out for official guidance or patches addressing common cache key misconfigurations.
