How do content delivery networks work?

How a CDN routes users to the closest cache

A CDN is not just “many servers on the internet”; it is a request-routing and caching system. The user’s browser, app, or API client is directed to an edge location that can serve the requested asset with less round-trip delay than the origin. That routing decision is usually influenced by DNS, anycast, or application-layer steering, and the response may be served entirely from cache or fetched from origin on a cache miss.

The practical effect is that the origin no longer has to handle every request for static or semi-static content. That improves latency, reduces bandwidth pressure, and gives the service more headroom during traffic bursts. For site operators, the important design question is which content should be cacheable, how long it should live at the edge, and what must always come from the origin.

DDoS Protection Guide is useful here because CDN design often sits on the same boundary as traffic absorption, scrubbing, and origin shielding.

What actually happens on a cache hit, miss, and purge

On a cache hit, the edge server already has a valid copy of the object and returns it immediately. On a cache miss, the edge fetches the object from origin, stores it according to the cache policy, and then serves it to the requester. A purge or invalidation event forces the CDN to discard stale copies so the next request repopulates the edge with fresh content.

This is why cache rules matter so much. Cache keys, TTLs, headers, query-string handling, and vary rules determine whether users receive the right object and whether the CDN can safely reuse a stored response. A small mistake in cache-key design can produce surprising behaviour, from stale pages to cross-user content leakage.

That same mechanism is also why invalidation needs discipline. If teams rely on manual purges for every update, they often create lag, inconsistency, or accidental over-purging. If they over-cache dynamic pages, they can serve the wrong version of content long after the origin has changed.

Why CDNs matter for resilience and security

CDNs improve resilience because they distribute load across many edge nodes instead of concentrating it at one origin. They also create a security boundary that can filter requests, absorb spikes, and reduce the direct exposure of the origin server. When the CDN is configured well, it becomes harder for ordinary traffic surges and some volumetric attacks to overwhelm the application.

They also introduce new failure modes. If the origin can still be reached directly, attackers may bypass edge protections and target the backend itself. If private or personalised content is cached incorrectly, users can receive data they should never see. And if an attacker can influence cached responses, a cache-poisoning issue can turn a performance layer into a delivery channel for malicious or misleading content.

The operational reality is that CDN security is mostly about boundary control, not just speed. The edge must be able to distinguish public from private content, enforce origin access restrictions, and preserve the integrity of the response content that gets reused at scale.

OWASP API Security Top 10 is relevant when the CDN fronts APIs, because authorization errors, inventory gaps, and resource exhaustion risks can be amplified by edge caching and routing.

Risk and Threat Considerations

CDNs reduce exposure, but they also concentrate trust in the cache layer, the routing layer, and the origin access path. A misstep in any one of those areas can expose private data, let an attacker poison content, or leave the origin reachable when it should have been shielded.

Failure mechanism: Weak cache rules, unsafe invalidation, or permissive origin access allow stale, private, or attacker-influenced content to be delivered from a trusted edge location.

Impact: Users may see the wrong content, sensitive data may leak across sessions or tenants, and the origin may become a direct attack target even when the CDN is present.

DDoS Protection Guide also maps to the attack side of the problem, because CDN misuse and bypass often show up alongside traffic floods, origin pressure, and edge-layer abuse.

Practitioner Guidance

What to verify: Confirm which responses are cacheable, which headers control freshness, and whether the origin is reachable only through the CDN. If private pages, authenticated API responses, or tenant-specific assets can be cached, treat that as a design defect until proven otherwise.

Decision rule: If a response can vary by user, tenant, session, or authorization state, keep it out of shared cache unless you have a clear, tested keying and isolation strategy. If it is public and stable, optimise for edge delivery and clear invalidation rules.

Common mistake: Teams often tune CDNs for performance first and discover the security boundary later. The safer pattern is to define origin protection, cacheability, and purge behaviour before broad rollout, then validate them under load and during content changes.

Practitioner takeaway: Treat the CDN as a controlled distribution layer, not a transparent accelerator, because most serious failures come from incorrect assumptions about what may be cached, who may reach the origin, and how quickly stale content is replaced.

Related resources from NHI Mgmt Group

• Content Delivery Networks (CDN)
• Why do AI agents make content delivery a governance issue?
• Which frameworks are most relevant when identity work moves into service delivery?
• How should organisations test whether age-based content controls really work under abuse?