Quick answer
A content delivery network (CDN) is a group of servers distributed across many locations that store copies of your content and serve it to visitors from whichever location is closest to them. Instead of every request travelling to your single origin server, most are answered nearby. This cuts latency, reduces the load your own infrastructure has to handle, and — because a cached response never touches your origin — absorbs a large share of attack traffic as a side effect.
How a CDN works
When a visitor requests a file, DNS directs them to the nearest CDN location rather than to your server. If that location already holds a fresh copy, it is served immediately — a cache hit. If not, the CDN fetches it from your origin once, keeps a copy, and serves every subsequent request from its own storage — a cache miss followed by hits.
How long a copy is kept is controlled by cache headers your origin sends, chiefly `Cache-Control`. A static asset with a long lifetime might be served from the edge for a year; an HTML page might be revalidated every few minutes; a logged-in dashboard should never be cached at all.
# Hashed asset — safe to keep for a year
Cache-Control: public, max-age=31536000, immutable
# HTML — cache briefly, revalidate after
Cache-Control: public, max-age=60, stale-while-revalidate=600
# Anything personalised — never store
Cache-Control: private, no-storeWhat you actually get
- Lower latency — distance is physics, and a response from 30 km away beats one from 3,000 km
- Less origin load — cached responses never reach your server, so it can be smaller
- Traffic spikes absorbed — a viral page is served from the edge instead of melting your origin
- Lower bandwidth bills — you pay for the cache fill, not for every visitor
- Attack resilience — flood traffic hitting cached URLs is answered without your origin noticing
The part that goes wrong: caching the wrong thing
The most damaging CDN misconfiguration is caching a personalised response and serving it to someone else. If a page containing one user's name, cart or session is stored at the edge, the next visitor may receive it. This is a data breach caused by a caching rule.
The safeguards are straightforward but must be deliberate: never cache responses that set a session cookie, never cache requests that carry an `Authorization` header, and treat anything behind a login as uncacheable unless you have thought carefully about it.
Tiered caching and cache stampedes
A naive CDN has a problem when something popular expires: every location that gets a request at that moment goes to the origin at once, and a single expiry becomes a burst of simultaneous requests. This is a cache stampede.
Two mechanisms prevent it. Request coalescing means concurrent misses for the same URL at one location produce a single origin fetch, with the others waiting for its result. Tiered caching adds an intermediate layer, so edge locations fetch from a regional cache rather than all reaching your server independently.
Why CDNs and security belong together
A CDN and a WAF occupy the same position: both are a reverse proxy sitting between your visitors and your origin. Running them as one system rather than two means a request is terminated once, inspected and served or forwarded in a single hop — instead of paying the cost of two proxies in sequence.
It also makes caching part of your defence. During an attack, requests for URLs already in cache are answered at the edge and never reach your origin. Attack traffic aimed at cacheable content is, from the origin's point of view, absorbed for free.
Frequently asked questions
Last updated