Edge servers, cache headers (Cache-Control, ETag, Last-Modified), cache invalidation strategies, CDN origin shielding, reverse proxies, Varnish, and how Cloudflare/Fastly make the web fast.
Content Delivery Networks (CDNs) are the backbone of modern web performance. By caching content at edge servers distributed around the world, CDNs reduce latency, offload traffic from origin servers, and protect against traffic spikes. Understanding how caching works - and the headers that control it - is essential for any web developer or security engineer.
A CDN is a network of proxy servers deployed across multiple data centres worldwide. When a user requests a resource, the CDN routes the request to the nearest edge server. If the edge has a fresh copy of the resource in its cache, it returns it immediately - a cache hit that can be 10-100x faster than going to the origin. If not, the edge fetches from the origin, caches the response, and forwards it - a cache miss.
The most important tool for controlling caching behaviour is the Cache-Control header. This header carries directives that tell both browsers and intermediate caches how to handle the response:
max-age=<seconds> - how long the response may be cached by the browser or private cache.s-maxage=<seconds> - overrides max-age for shared caches (CDNs, reverse proxies).no-cache - the response must be revalidated with the origin before every use.no-store - the response must never be cached under any circumstances.must-revalidate - stale responses must not be served without origin validation.public / private - whether the response can be cached by shared caches or only by the browser.Beyond time-based invalidation, HTTP provides two mechanisms for conditional requests. The ETag response header carries a unique identifier for a specific version of a resource (usually a hash of its content). The client can send this value back in the If-None-Match request header; if the content has not changed, the server responds with a 304 Not Modified status and no body. Similarly, Last-Modified paired with If-Modified-Since allows revalidation based on timestamps.
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600, s-maxage=86400
ETag: "abc123def456"
Last-Modified: Mon, 17 Mar 2025 12:00:00 GMT
Content-Type: application/json
{"status": "ok"}CDNs also support explicit cache invalidation strategies. Purge by URL removes a specific resource from all edge caches immediately. Purge by tag (or surrogate key) lets you tag related resources - for example, tagging all pages that reference a product - and invalidate them all at once. Providers like Fastly and Cloudflare use surrogate keys extensively for fine-grained cache management.
Origin shielding is a caching pattern where a designated edge server acts as the single point of contact for the origin, absorbing all cache misses from other edges. This prevents a thundering-herd problem where dozens of edges simultaneously request the same uncached resource from the origin.
Use the simulator below to explore how a CDN edge server handles requests. Enter a URL, see the cache hit/miss flow, inspect response headers, and test what happens when the origin goes down.
x-cache header tells you whether the response came from the edge (HIT) or origin (MISS).stale-while-revalidate is configured.Proper cache configuration can reduce origin server load by 60-90% and cut page load times by 2-5x for returning visitors. Major CDN providers - Cloudflare, Fastly, Akamai, and AWS CloudFront - power most of the internet's content delivery. A single cache miss that hits the origin can add 200-500ms of latency; a cache hit at the edge serves content in under 10ms.
The security implications of misconfigured caching are severe. Web cache deception (also called cache poisoning) is an attack where an attacker tricks a CDN into caching a sensitive response - such as a page containing personal data or an API response with authentication tokens - and then serves it to other users. This typically exploits discrepancies between how the CDN and the origin server interpret URL paths or query parameters.
To prevent cache poisoning and other caching-related vulnerabilities, follow these practices. Always use Cache-Control: no-store for responses containing sensitive data (personal information, session tokens, API keys). Never cache responses that depend on authentication state. Set Cache-Control: private for user-specific resources so they are stored only in the browser cache, not in shared CDN caches.
For dynamic content that changes infrequently, use short max-age values combined with ETag or Last-Modified for efficient revalidation. Validate the Vary header to ensure the CDN does not serve a cached response meant for one user agent or encoding to another. Consider using surrogate keys for finer-grained cache invalidation - they let you purge related resources without knowing their exact URLs.
# Safe caching for authenticated content
Cache-Control: private, no-store, must-revalidate
# Safe caching for public but dynamic content
Cache-Control: public, max-age=60, must-revalidate
ETag: "v2-abc123"
# Aggressive caching for static assets
Cache-Control: public, max-age=31536000, immutable1.What does the Cache-Control: no-store directive mean?
2.How does an ETag header enable efficient revalidation?
3.What is web cache deception?