CDN — Cache Poisoning, Serve-Stale, Multi-CDN & Media / Tail-Latency

The core CDN pages cover architecture, push-vs-pull, and TTL-bounded staleness. This page adds the senior layer: the two security attacks unique to shared edge caches, how a CDN doubles as an availability shield (not just a latency layer), what real multi-provider failover costs, how large media is actually cached, and why tail latency — not the average — is the number that matters.

1. Web cache poisoning via unkeyed input

A CDN keys each cached response by a subset of the request — typically (method, host, path, maybe some query params). Anything not in the key is "unkeyed". If the origin reflects an unkeyed input (a header like X-Forwarded-Host, X-Forwarded-Scheme, or a non-keyed query param) into the response, an attacker sends one request to a clean URL with a malicious header; the origin bakes the payload into the HTML; the edge stores it under the clean key and then serves the poisoned page to every subsequent victim — who send a perfectly normal request. This is distinct from an accidental personalization leak (caching one user's private response): poisoning is deliberate and persistent, and one request can affect everyone until the entry expires.

Fix: include any reflected input in the cache key (so the poisoned variant only serves back to the attacker), or — better — never reflect unkeyed request data into cacheable responses; strip untrusted forwarding headers at the edge.

2. Cache deception (path confusion)

Edges often decide "is this cacheable and public?" from the URL suffix: a .css/.js/.jpg path is treated as a static public asset and cached aggressively. An attacker lures a logged-in victim to /account/statement/nonexistent.css. Many origins route this to the real /account/statement handler (ignoring the trailing segment) and return the victim's private page — but the edge sees .css, caches it as public, and the attacker then fetches the same URL and reads the victim's data out of the shared cache.

Fix: cache by the origin's declared intent (Cache-Control / Content-Type), not the URL extension; make the origin 404 unknown suffixes rather than routing them to the base handler; normalize/reject path traversal at the edge.

3. serve-stale-on-error: the CDN as an availability shield

The unit teaches the CDN as a latency/offload layer. It is also an availability layer. Two distinct directives:

• stale-while-revalidate — origin is slow but up: serve the (just-)stale copy instantly and refresh in the background. Optimizes latency.
• stale-if-error (serve-stale-on-error) — origin is down (5xx/timeout): serve the last good copy past its TTL rather than propagating an error. Optimizes availability — the site stays up through an origin outage.

Across the tier hierarchy (edge → regional shield/mid-tier → origin), stale-if-error lets each layer absorb the one below it: a regional shield can serve stale to many edges even while the origin is dead. The trade-off is explicit and worth stating in an interview: users may see stale data during the outage, but they get a working site instead of a 503.

4. Multi-CDN and provider-level failover

"Run both" inside one provider (anycast + DNS) survives a POP failure, not a whole-provider outage (control-plane bug, cert expiry, routing incident) — which have taken large fractions of the web down. Real resilience is multi-CDN: two vendors behind DNS-based or managed traffic steering (latency/health/weight), failing the whole zone over on provider-level health signals.

The catch is the cold-cache cost: after failover, the second CDN's caches are empty, so the first wave of traffic is a miss storm that all hits your origin at once — exactly when things are already fragile. Mitigate with pre-warming, capacity headroom at the origin, and request coalescing at the new edge. Multi-CDN also multiplies cost, config surface, and purge/invalidation complexity (you now purge two networks consistently) — reserve it for tiers where a provider outage is unacceptable.

5. Large media: Range requests and segment caching

A 200 MB video is never cached as one object. Clients issue HTTP Range requests, and the CDN caches byte-range segments (or, for HLS/DASH, the individual chunk files) independently. Consequences worth knowing: a seek to the middle fetches/caches only that segment (not the whole file); a partial view only warms the segments watched; and the origin must support range requests (Accept-Ranges: bytes, 206 Partial Content) or the CDN can't slice. This is why per-object hit ratio is the wrong metric for video — you measure it per segment.

6. Name the consistency model, and frame the tail

Consistency: TTL caching provides bounded staleness (eventual consistency with a bound = TTL). You only get read-your-writes after a purge/invalidation has propagated to all edges — and propagation is itself eventual (seconds, occasionally longer). Say this explicitly rather than implying fresh reads.

Tail latency: single-request averages hide the fill path. A hit is ~1–20 ms at the edge; a miss pays the full origin RTT (tens to hundreds of ms), and a partial hit pays it for the missing segment. So p99 is dominated by misses, first-byte-after-purge, and cold edges after failover — not by the hit path everyone quotes. Optimize (and SLO) on the miss/fill distribution, not the mean.

Pitfalls

• Reflecting unkeyed headers into cacheable HTML → one attacker request poisons the page for everyone.
• Caching by URL suffix instead of declared content-type → cache-deception disclosure of private pages.
• Treating the CDN as latency-only → no stale-if-error, so an origin outage becomes a full site outage.
• Single-CDN "resilience" → survives a POP but not a provider incident; and any failover to a cold network stampedes the origin.
• Quoting the average latency → hides that p99 is the miss/fill path.

Judgment layer — when to reach for each

• stale-if-error: use whenever brief staleness beats an error (most content sites). Do NOT use for data that is dangerous when stale (prices, balances, auth) — fail fast there.
• Multi-CDN: use for revenue/availability-critical delivery where a provider outage is unacceptable. Do NOT for early-stage/low-traffic — the cost, config, and dual-purge complexity outweigh a rare provider blip; a single CDN with good stale-if-error is the cheaper 90% answer.
• Segment caching: mandatory for large media; irrelevant for small API/HTML responses (cache whole).
• Keying strategy: key on everything that changes the response (defeats poisoning) but no more (over-keying destroys hit ratio) — the security/efficiency trade-off.

Takeaways

• Shared edge caches add two attacks the origin alone doesn't have: poisoning (unkeyed reflected input) and deception (suffix-based caching of private pages). Fix both at the key/intent level.
• stale-if-error turns a CDN from a latency layer into an availability shield — the single highest-leverage resilience directive.
• Multi-CDN survives provider outages but every failover is a cold-cache origin stampede — plan capacity and pre-warming.
• Large media is cached per Range segment; and p99 is the miss/fill path, not the hit — SLO accordingly.

Re-authored/Deepened for this guide.