Every control you configure at the edge — WAF, rate limits, bot rules, DDoS absorption — assumes traffic goes through the edge. If an attacker can reach your origin directly, none of it applies: they inherit a clean path to the weakest server you own. Origin protection is a ladder with four rungs, and most breaches of “CDN-protected” sites happen because a team stopped at rung one.
The bypass problem
Attackers find origins routinely, and rarely by luck. Historical DNS databases remember the A record from before you moved behind a CDN; a subdomain you never proxied (mail., staging., ftp.) still points at the same network; Certificate Transparency logs publish every certificate you ever requested, hostname included; outbound email headers can carry the sending server’s address; and internet-wide scanners index every host that answers with your certificate or a distinctive response body. Assume the IP is discoverable and design so that discovery is useless — that is the actual goal, and it reframes everything below.
Rung 1: IP hygiene — hide it and keep it hidden
Hygiene still matters because it raises the attacker’s cost. When you first move behind a CDN, get fresh origin addresses — the old ones live in DNS history forever — and audit every record in the zone for stragglers that point at the new range. Send email from a separate network, keep the origin’s certificate names boring (a wildcard or a name that does not advertise its role), and check your own exposure the way an attacker would: search the historical-DNS services and scan databases for your netblocks. Do this on a schedule, because the leak you plugged last year reopens with one careless DNS change — it belongs on the quarterly audit.
Rung 2: allowlist the edge ranges (and their limits)
Next, configure the origin firewall to accept HTTP(S) only from your CDN’s published ranges. Every major provider publishes them — Cloudflare’s IP list, Fastly’s public IP list, AWS’s managed prefix list for CloudFront, Akamai’s Site Shield maps — and the good platforms give you an API or managed object so the allowlist updates itself; a hand-typed list rots the first time the provider adds a range. Understand what this rung does and does not prove: it blocks the random internet, but on a shared CDN the ranges are shared by every customer, and a bypass technique documented publicly since 2023 is to sign up for the same CDN, point a distribution at your origin IP, and ride the trusted ranges straight past your edge rules. An allowlist is necessary; it is not identity.
Rung 3: authenticate the edge — headers and mTLS
Identity comes from something only your distribution carries. The simple version is a secret header: the CDN injects a long random value on every origin fetch and the origin rejects requests without it. It closes the shared-tenant hole, costs an hour to deploy, and its weaknesses are operational — the secret sits in two configs, must rotate on a schedule, and leaks if the origin ever echoes headers into logs or error pages. The strong version is mutual TLS: the edge presents a client certificate and the origin verifies it cryptographically. Cloudflare’s Authenticated Origin Pulls is the well-known implementation — use the zone-level mode with your own certificate, because the default shared certificate only proves “some Cloudflare customer,” recreating the tenant problem one level up. Akamai, Fastly and CloudFront all support equivalent client-certificate arrangements. mTLS plus the rung-2 allowlist is the right resting point for most production estates.
Rung 4: private connectivity, and the audit
The top rung removes the public path entirely. CloudFront’s VPC origins (launched November 2024, at no extra charge) let the edge fetch from load balancers and instances in private subnets with no public IP at all; Cloudflare offers dedicated egress addresses via Aegis and private interconnects for enterprise plans; Akamai’s Site Shield narrows fetches to a small announced map that pairs with strict ACLs. Private connectivity is the answer when the origin fronts payments, credentials or anything an unmasked origin would make front-page news — and it changes your incident options, because an origin with no public path cannot be “failed open” in a CDN outage, a trade-off to note in the incident playbook. Whichever rung you stop at, verify it empirically: from an unrelated network, request your site against the origin IP directly with the right Host header. The correct result is a refusal. If content comes back, everything above the origin is decoration — and an origin taking full traffic unshielded also has capacity implications, covered in reducing origin load.