Prevent shared-cache poisoning and private-response deception

A shared cache is a second response-serving component. On a hit it may return bytes before origin authentication, authorization or application logging executes. Its security contract therefore includes audience, representation, freshness and invalidation, not just a performance key. A perfectly correct origin permission check cannot fix a private response already served from an inappropriate cache entry.

Cache poisoning makes a request produce an undesirable response that is stored under a key also used by ordinary requests. Cache deception instead causes personalized content to be classified as publicly cacheable, often because the cache and origin interpret a path differently. Both involve a mismatch, but the first question in an investigation differs: which omitted input changed the response, or why was this private response considered eligible?

For C1, the origin includes locale in the catalogue response, but the cache key drops the query string. A request for French warms /catalog; a later English request receives the French representation. Keeping the complete request target fixes this particular collision. It does not settle whether the response is public or whether a future header starts changing it.

For C2, Alice warms /private and Bob receives Alice’s invoice on a hit. Adding tenant to the key still shares data among different users inside that tenant and ignores no-store. The local project takes a simple explicit policy: authenticated or cookie-bearing requests bypass both cache lookup and storage. This is the project’s contract; HTTP itself lets a shared cache store an authenticated response when the response explicitly allows it, for example with Cache-Control: public.

For C3, a synthetic origin routes every /account/... path to a private account controller. A synthetic cache rule classifies *.css as public. The private response for /account/export.css is now a candidate for public reuse even if the attacker never knew its contents in advance. The repair must address route fallback and cache eligibility. Renaming a URL alone leaves the disagreement available elsewhere.

C1: key=pathname; /catalog?locale=fr and /catalog?locale=en both become /catalog
C2: key=method+path; Alice GET /private stores Alice invoice; Bob hits same key
C3: cache marks *.css public; origin maps /account/* to current account
Project contract: only anonymous GET with no Cookie; exact public response directive; no Set-Cookie; no unsupported Vary.
C3 is a paper fixture; the local project implements C1/C2 and additional cache/header checks.

Write the contract route by route. Which requests can read a shared entry? Which responses can create one? Which dimensions change its representation? How long is reuse permitted, and what invalidates it? A key cannot compensate for ineligible content, and checking storage alone cannot prevent a later unauthorized lookup of an existing entry.

RFC 9111 distinguishes private, no-store, freshness and revalidation. private constrains shared storage; no-store directs caches not to store. no-cache requires validation before reuse rather than simply forbidding storage. Authorization has special shared-cache rules with explicit exceptions. Use supported cache implementations for these semantics; a homemade string check is only appropriate when the producer and consumer deliberately enforce a narrow teaching contract.

Vary identifies request header dimensions used to select a representation. The project does not implement that machinery and therefore bypasses any response carrying Vary. It also refuses Set-Cookie responses under its conservative contract. These explicit limitations are preferable to claiming that a small map is a general HTTP cache. New origin behavior must update the cache contract and tests together.

nginx implements much of RFC 9111, but not its rule for Authorization. With a plain proxy_cache in nginx 1.30.5, an origin response marked only max-age=60 to a request carrying Authorization: Bearer alice was stored and then served to Bob and to an anonymous client. The configuration below closes that gap: any request with an Authorization header or a cookie bypasses both lookup and storage. In the same test Alice and Bob each received their own data, the public catalogue returned MISS then HIT with one origin request, ?locale=en got its own entry because the key keeps the full target, and a response marked private was not stored.

nginx also refuses to store responses with Set-Cookie or Vary: *, and stores other Vary values as separate variants. None of that protects a personalized response the origin labels as public, so the origin header and the cache rule must agree.

# Shared cache at the edge (nginx 1.30). nginx does not apply RFC 9111's Authorization rule,
# so requests that carry credentials must bypass the cache explicitly.
proxy_cache_path /var/cache/nginx/edge keys_zone=edge:10m max_size=1g inactive=10m use_temp_path=off;

map "$http_authorization$http_cookie" $credentialed {
    ""      0;
    default 1;
}

server {
    listen 8080;

    location / {
        proxy_pass http://cacheorigin:8080;
        proxy_cache edge;
        proxy_cache_key $scheme$host$request_uri;  # the full target, query included
        proxy_cache_bypass $credentialed;          # never answer a credentialed request from cache
        proxy_no_cache $credentialed;              # never store the response to one
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

Download the proxy/cache project linked with this guide and run node observe.mjs. Alice receives a MISS with tenant acme. Bob then receives a HIT containing Alice’s invoice. This is a real response from the local proxy; no network mock returns the expected data for the test.

Run node --test exercise.test.mjs. The starter passes four cases and fails eight. In exercise.mjs, preserve method and the full target in cacheKey, bypass authenticated/cookie requests in mayReadCache, and require the narrow public contract in mayStore. Keep validHeaders consistent with the framing guide at /domains/runtime/edge-defense/http-request-desynchronization/. The reference command EXERCISE_MODULE=reference node --test exercise.test.mjs passes all twelve tests.

Keep the public-cache positive control. Two anonymous /catalog requests must still produce MISS then HIT with one origin invocation. A patch that disables all cache reads avoids the disclosure but does not implement the stated functional requirement. Compare body content, cache status and origin count; a response header alone does not prove whose bytes were delivered.

A route that accepts arbitrary suffixes can turn a static-looking URL into a private controller. Prefer exact route matches for private features, reject unexpected suffixes, and derive eligibility from an explicit route/response contract rather than extension alone. Check encoded separators, normalization and redirects in your own stack; different intermediaries can transform a target at different stages. PortSwigger's 2024 research showed how: a semicolon that Spring treats as a delimiter, an encoded # or an encoded dot-segment can make a cache see /static/x.css while the origin serves /account. Its advice is to mark dynamic responses no-store and private, make sure cache rules cannot override Cache-Control, and avoid normalizing the cache key differently from the origin.

An origin that uses forwarded host or other client-influenced metadata to construct links can produce different responses for requests with the same cache key. Trust only headers established by a trusted proxy, as the API gateway inventory guide at /domains/runtime/api-security/api-gateway-inventory/ describes, strip client duplicates and keep canonical URL construction independent of untrusted forwarding inputs when possible. Adding every attacker-controlled header to the key can also create unbounded cache cardinality; the right repair may be to remove the input’s influence.

Cloudflare’s cache-deception protection compares extension and response type for a documented class of mismatch, with documented exceptions and override interactions. Treat it as a product-specific additional control. Confirm effective rule ordering and origin directives on the actual account; an enabled switch cannot establish that every personalized route is safe.

Use isolated caches and synthetic users for an authorized test. Start empty, warm using A, request using B, then reverse the order. Exercise an anonymous request after an authenticated warm-up, cookie-bearing requests, changed query/header dimensions, redirects and errors. Keep representative successful public hits. Record origin execution so a hidden bypass is visible.

After a confirmed leak, disable or repair the unsafe reuse rule and purge affected entries at every relevant layer. Changing an origin header does not necessarily remove entries already stored downstream. Bound the exposure window using cache lifetimes and available request evidence; avoid claiming that cache purge can recall responses already delivered to clients.

For a policy rollout, compare origin load as well as correctness. A cache fix can increase traffic to a previously bypassed backend. Capacity planning is not a reason to preserve a disclosure, but it is part of deploying the repair reliably. Document the owner who must update the cache contract when a route starts returning personalized data.

The project deliberately whitelists one public contract. This table is its acceptance matrix, not a general-purpose interpretation of every possible Cache-Control value.

The project runs one Node origin and proxy with a bounded 30-second in-memory cache. It does not implement browser caching, a CDN, distributed invalidation, stale response rules or multi-region propagation. The deception scenario is a self-contained design review; it is not falsely presented as a feature of that executable. Finish by mapping the same cases to the actual cache product and saving observed outcomes against its effective configuration.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. RFC 9111: HTTP caching semantics. June 2022.
2. Cloudflare: avoid web cache poisoning
3. Cloudflare: cache deception protection and exceptions
4. NGINX proxy cache configuration
5. RFC 9111 §3.5: storing responses to authenticated requests. RFC 9111 (June 2022).
6. PortSwigger Research: Gotta cache 'em all (2024)
7. PortSwigger Web Security Academy: web cache deception

Reference information

RFC 9111 and Node.js 22+; verify each deployed CDN configuration.

Tags

Access controlMulti-tenancyProxies, caches and request smuggling

SDLC phase

DesignMaintenance

Role

DevelopersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-14.2.2 · v5.0.0-14.2.5

CAPEC attack patterns

• CAPEC-141 at MITRE

Download this guide as Markdown

Continue exploring