A service reflects the request's Origin header into the Access-Control-Allow-Origin response header, and a CDN caches those responses. Browsers on some sites start reporting CORS failures while others receive a permissive value they should not. What is missing, and why does it produce exactly this symptom?

## The mechanism being cached Cross-origin requests from a browser carry an `Origin` request header naming the calling site. The server decides whether that caller is allowed and answers with `Access-Control-Allow-Origin`. Because the header can name only one origin (or the wildcard `*`), servers supporting several allowed sites typically **reflect**: look up the request's `Origin` in an allowlist and, if it matches, echo it back. Reflection means the response's headers are a function of a request header. That is content negotiation, and every cache in the path must be told about it, exactly as with `Accept-Encoding`. ## Why the symptom looks the way it does Without `Vary: Origin`, the cache stores one response per URL. Which allow-origin value it holds depends on whoever missed the cache first — per edge node, per region, per cache generation. - A browser whose origin does not match the cached value blocks the response. The application sees a CORS error even though the server-side allowlist is correct. - Reloading may fix it (different edge node, different variant) and break again later, which is why it is often reported as flaky rather than broken. - The mirror image is worse: a site that is **not** on the allowlist can receive a stored response that carries an allow header, or an origin you removed from the allowlist keeps being allowed by cached copies until they expire. Browser same-origin protection is the thing being weakened, so this belongs in the security bucket, not the performance bucket. When credentials are involved (`Access-Control-Allow-Credentials: true`, which forbids the wildcard) the reflected value is the only option, and the missing `Vary` becomes correspondingly more serious. ## The fix, completely 1. **Emit `Vary: Origin`** on every response that reflects the origin — not only successes. Redirects, 4xx and 5xx responses that carry CORS headers need it too, since caches store those as well. 2. **Cover the preflight.** The `OPTIONS` preflight response is negotiated on `Origin`, and also on `Access-Control-Request-Method` and `Access-Control-Request-Headers` if you compute the answer from them. The full value is often `Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers`. 3. **Do not clobber existing values.** `Vary` is a list; appending `Origin` to an existing `Vary: Accept-Encoding` must produce `Vary: Accept-Encoding, Origin`. Frameworks that set rather than append are a common source of the bug — CORS middleware overwrites the compression middleware's header or vice versa, depending on ordering. 4. **Watch the edge.** Some CDNs drop or reorder request headers before computing the key, and some strip `Vary` values they do not recognize. Verify empirically by requesting the same URL twice with different `Origin` values through the same edge and comparing the returned allow header and cache-status header. ## Alternatives that avoid the variation - If the resource is genuinely public and credential-free, answer with a constant `Access-Control-Allow-Origin: *`. It does not depend on the request, so there is nothing to vary on and the cache stores a single copy — the best hit rate available. - If only two or three origins are allowed, you still reflect, but the variant count is tiny and the cost of `Vary: Origin` is negligible. - If the allowlist is large and the resource is hot, consider serving it from distinct hostnames or paths per tenant so the variation is expressed in the primary key. ## How to test for it Issue the same request twice through the cache with different `Origin` headers and inspect what comes back. If the second response echoes the first origin, or the responses lack `Vary: Origin`, the bug is present. A useful guard in CI is an assertion that any response containing `Access-Control-Allow-Origin` with a value other than `*` also contains `Origin` in its `Vary` list. ## The general rule Anything the server reads from the request to build the response must appear in `Vary` — `Origin` is simply the case people forget because CORS feels like a browser concern rather than a caching one. It is both.