A bypass needs three conditions at once
Applying a CDN or a WAF does not automatically make the origin server private. A CDN and a WAF inspect only the requests that cross them. If the origin's public IP, an old DNS record, another hostname, a directly connectable port, an IPv6 address, or a load balancer endpoint remains, and the origin accepts that request, the WAF, rate limit, bot, and DDoS controls in front are skipped.
The goal of origin protection is not to keep the address unknown. It is to make the application unreachable except through an approved edge path, even once the origin address is known. Current Cloudflare, AWS, and Azure documentation likewise states that blocking direct origin access requires at least one of removing the public route, restricting the network, or authenticating the origin — enforced at the origin itself.[2][7]
Describing origin exposure in one word blurs the priority of the remedies. This article splits it into three conditions. A bypass path exists when the endpoint can be identified, a direct connection can be made from the internet or another unapproved path, and the origin accepts that connection and request as legitimate. If the origin hostname is public but sits inside a private network with no external route, no direct connection is possible. Conversely, even with a public IP, if the origin accepts only edge connections presenting a particular client certificate, an ordinary request never reaches the application.
Replacing the address or cleaning up DNS lowers the first condition, discoverability. Firewalls and private networks reduce the second, direct connectivity. mTLS, origin authentication, per-deployment identifiers, and secret headers restrict the third, request acceptance. One layer can close a specific path on its own. But allowing for configuration changes and operational mistakes, the audit standard this article recommends is verifying two layers independently — the network path and origin identity. NIST's zero trust principles likewise refuse to treat network position as a basis for trust and require a policy enforcement point in front of the resource to control every request.[1]
The target state fits in one sentence. Users reach the origin, load balancer, and application only through the CDN, WAF, and edge, over a private route or a restricted network with an authenticated origin connection. The path from the internet to the origin's public route and the path from an unapproved edge through origin authentication are both closed, and administrators reach the management plane on a separate path only.
The main paths by which an origin is exposed
A public IP does not disappear because DNS hides it. Even where the production domain returns only the CDN's IP, public IPs remain on VMs, load balancers, Kubernetes ingress, and firewall appliances. A DNS proxy only stops the origin IP appearing on a lookup; it does not remove the address's reachability. Cloudflare also advises auditing existing records and replacing the origin IP after the edge cutover, because DNS-only records and historical DNS data can retain the origin IP.[2] Replacing the IP invalidates the old address and lowers exposure of the new one. If the new IP is again open and accepts direct requests, the structural problem remains.
Old DNS and certificate information are audit clues for the defender. Deleted A, AAAA, and CNAME records survive in historical data and operating documents. Where public TLS certificates are logged to certificate transparency, the names in the certificate become an asset audit clue too. RFC 9162 defines the structure that logs public TLS certificates to a log anyone can audit.[3] The wrong conclusion is "hide every name". Public certificates and DNS are inherently publishable information. The operator checks past names in the domains and certificate inventory they manage, but the final defence is a state where connecting directly by that name is refused.
Alternate hostnames and default endpoints bypass the production domain. Only the production domain crosses the CDN while origin-only hostnames, old service domains, staging, preview, and beta hostnames, cloud-generated load balancer DNS names, serverless and PaaS default domains, separate addresses for Kubernetes ingress or gateways, and backend endpoints left for external integrations connect straight to the origin. Where those paths are needed for the business, apply the same network and identity controls as the official edge. Where they are not, disable public access or decommission them. Restricting host header and SNI to expected values reduces the mistake of a default virtual host exposing the application. But a hostname is not secret, so host validation cannot substitute for edge identity.
Closing 80 and 443 while leaving other ports open is common. Origin protection policy applies to 80 and 443 while a separate web port, debug port, health port, management panel, or temporary listener stays open to the whole internet. The same problem appears where a container port or backend service is exposed directly on the node or VM without passing the public load balancer. The audit is based not on a design document saying "web services use 443" but on cloud firewalls and security groups, network ACLs, load balancer listeners, host OS listeners, container and Kubernetes services, ingress and gateways, firewall port forwarding, and the ports actually listening in the current runtime. Where a health check is required, allow only the provider's stated health check source or an internal monitoring path rather than the whole internet.
IPv6 is not an extension of the IPv4 firewall. In a dual-stack environment IPv4 and IPv6 are separate connection paths. Even with the IPv4 public IP closed, a remaining AAAA record, a VM's global IPv6, a dual-stack load balancer, or a ::/0 inbound rule allows a direct connection over IPv6. AWS documentation treats 0.0.0.0/0 and ::/0 as separate "anywhere" rules and explains that IPv6 operation needs its own inbound rules and flow log review. CISA likewise recommends applying management plane controls equivalent to IPv4 wherever IPv6 is enabled. "We do not use IPv6" is not sufficient as an answer. The actual enabled state has to be checked in DNS, load balancers, VM interfaces, container networking, and the firewall.
Management ports get mixed in with the application origin. Where SSH, RDP, a server control panel, database admin, or a Kubernetes dashboard sits on the same public IP as the application origin, the CDN and WAF do not protect that path. An edge that inspects ordinary HTTP requests and system management access differ in what they protect, who uses them, which protocol they carry, and what availability they need. This article does not compare VPN, bastion, and identity-aware access. One principle applies: the application data plane and the management plane are separated by different access paths and policies.
Cloud resource metadata and public assets reveal endpoints. Cloud consoles and IaC record public IPs, LB DNS names, serverless default URLs, ingress addresses, and service endpoints. The same information gets copied into CI output, operating documents, public repositories, and status pages. HTML, JavaScript, configuration, source maps, and redirect bodies delivered to the browser can also carry internal IPs and sensitive routes. OWASP WSTG advises reviewing production assets because client-side JavaScript and source maps can expose internal addresses, API details, and debug information. An API endpoint a public client has to call is naturally public. Visibility is not itself the vulnerability. The problem is when that endpoint is a separate path around the WAF or gateway and the origin accepts it as legitimate.
Shape delivery around the content — Set caching by update behavior and observe edge delivery alongside origin load.
What to check and what closes each path
The table below is not any provider's official grading. It is an editorial synthesis of current Cloudflare, AWS, Azure, Akamai, Google Cloud, NIST, IETF, and OWASP documentation against the origin security question.[1][2][5][6][7] The last column of each row is the caveat that remains even after the mitigation is applied.
Exposure path | Evidence to check in the audit | Primary mitigation | Supporting control | Caveat that remains |
|---|---|---|---|---|
| Origin public IPv4 | Public IP inventory of VMs, load balancers, and ingress, plus routes, firewall, security groups, and edge origin configuration | Remove the public IP and internet route, or move to a private origin. Where public exposure is required, default-deny and allow only approved edge sources | Per-account and per-deployment origin authentication, mTLS, default listener deny | Hiding or changing the IP is not access control |
| Old DNS record | The current zone plus migration records, records due for removal, historical operating documents, and the certificate inventory | Remove stale records, replace the origin address after the edge cutover, and decommission the connection paths of old IPs and hosts | DNS change review, recorded owner and removal date | Do not assume published historical records can be fully erased |
| Alternate hostname | Origin aliases, preview, staging, and legacy domains, PaaS and serverless default domains | Disable unnecessary public domains. Apply the same restrictions as the primary path to hosts you keep | Accept only expected hosts and SNI, fixed deny on the default virtual host | Hostname validation is not edge identity |
| Direct port | Every LB, VM, container, and ingress listener, port forwards, health and debug ports | Close unused listeners. Restrict required ports to approved sources and private networks | Per-listener mTLS, tokens, fixed deny, and a named port owner | 443 being safe does not stop another listener exposing the application |
| IPv6 | AAAA records, global IPv6, dual-stack LBs, IPv6 routes, ::/0 rules, IPv6 flow logs | Apply the same default-deny and allowlist, or private route, as IPv4 | Negative tests and drift checks split between IPv4 and IPv6 | Do not assume IPv4 rules apply to IPv6 automatically |
| Management port | SSH, RDP, control panel, database admin, and cluster admin endpoints and their public routes | Separate the management plane from the application origin. Remove public internet listeners | User and device identity, MFA, approval and audit, a separate break-glass policy | Availability and emergency procedure for management access need their own design |
| Load balancer and backend endpoint | Public LB DNS, backend services, direct target addresses, serverless default URLs | Private LB, private endpoint, VPC origin, or disabling public access | Verify provider IP ranges together with per-deployment identity | Check health check, protocol, and per-product private origin support limits |
| Certificate and historical DNS clue | Certificate inventory and SANs, CT monitoring of domains you own, past DNS change records | Treat names as public and close the route and origin auth for that endpoint | Reduce unnecessary origin-only public names, split certificates per environment | Public TLS names and DNS records remain auditable information |
| Cloud metadata and public assets | Cloud resource inventory, IaC and CI output, public repositories, JS, source maps, config, redirect bodies | Remove unnecessary internal endpoints and credentials, restrict debug asset deployment | Deny direct origin access, secret scanning, release review | A public API name can be legitimate. Separate visibility from permitted access |
HTTPS and origin access control are different things
In an ordinary HTTPS connection, a client that validates the certificate correctly protects the origin server's identity and the confidentiality and integrity of the transport. But using HTTPS does not by itself restrict who can connect to the origin.
TLS is a protocol for preventing eavesdropping, tampering, and message forgery, and RFC 9525 defines the procedure by which a client validates the service name it is connecting to against the identity in the server certificate.[4] Those make the connection to the origin safe, but ordinary server-authenticated TLS does not distinguish whether the client is a CDN edge or anyone else.
Where the origin also requires a client certificate through mTLS, it can verify that the edge holds the private key of a permitted certificate. The scope of identity being proven differs, though, depending on whether the certificate is shared across the whole provider or dedicated to a specific account, zone, or hostname. Cloudflare's distinction between global and account-scoped authenticated origin pull is one example.[5]
Which defence model to choose
Where the public route can be removed, look at a private origin first. Placing the origin in a private subnet, private link, VPC origin, or internal load balancer and connecting only over an edge-managed private path structurally reduces public IP, historical DNS, and direct port problems. AWS CloudFront VPC origin can use an ALB, NLB, or EC2 instance in a private subnet as the origin, and Azure Front Door can use private link to supported origins. Google Cloud likewise does not recommend connecting to a VM's external IP directly from the internet. A private origin is not always possible. Protocol, load balancer type, region, health check, existing networking, and provider product all impose limits. AWS VPC origin today, for instance, has limits on supported resources and NLB TLS listeners. Re-confirm the current official support scope before designing.
Outbound tunnels and connectors can remove the inbound listener. Making outbound-only connections from the origin to the edge network removes the public listener that accepts inbound traffic from the internet. Cloudflare Tunnel is of this type, and Cloudflare's documentation describes connecting the origin without a publicly routable IP. Six operational factors become newly important in this model: protecting and rotating connector credentials, high availability of connector instances, failover when the tunnel breaks, health checks and deployment order, provider outages and dependency, and closing any residual public route that does not pass the tunnel. For Cloudflare, a tunnel origin has no inbound listener, so authenticated origin pull is not layered on top and the connector credential authenticates the origin connection.[5]
Where the origin has to stay public, restrict network and identity together. Legacy systems, provider support limits, and external integrations sometimes force a public endpoint on the origin. In that case configure at least three conditions together. Default-deny keeps unapproved requests away from the application handler. Network source restriction allows only the provider-managed prefix list, service tag, stable CIDR, or edge IP range. Origin identity verifies through mTLS, a deployment identifier, a signature, or an origin credential that the request came from a specific account or deployment. Azure Front Door advises combining backend IP filtering with validation of the X-Azure-FDID profile identifier on a public origin, because the IP addresses are shared with other Azure customers so the network source alone cannot prove a specific Front Door profile. A stable IP allowlist such as Akamai's origin IP ACL also simplifies origin firewall operations, but where possible mTLS or origin authentication that authenticates the connecting party belongs in the review too.[6]
Use mTLS where identity is what you need. It fits where the origin has to validate a client certificate to confirm the identity of the edge or the calling service. Its value is highest where the origin must stay on a public network, where only a specific CDN account or deployment or B2B client should be allowed, where a shared provider IP range makes the identity scope too broad, where the organisation can run certificate issuance, distribution, rotation, and revocation, and where identity can be verified as preserved across every hop that terminates TLS. Conversely, in an organisation without certificate inventory, automatic rotation, key protection, revocation, and expiry alerting, mTLS becomes a new source of outages. Sharing one certificate across origins, or passing a proxy's validation result in a forgeable header, weakens the identity boundary you expected.
Treat secret headers as a supporting control. Having the CDN add a secret header to origin requests and the origin forward only matching requests is easy to apply even in legacy environments. AWS documents this pattern with a default 403 rule for putting a public ALB behind CloudFront. But it depends on the header name and value not leaking. AWS documentation states that it has to be treated like a credential, protected with HTTPS, and rotated periodically.[7] Seven rules follow when using one. Give it a name distinct from headers ordinary clients send. Manage it in a secret manager. Keep the value out of logs, traces, and error pages. Rotate it with dual values for zero downtime. Keep missing and mismatched requests away from the application. Pair it with an edge IP allowlist where possible. Review the long-term move to a private path or stronger origin authentication.
- Private origin
- A private origin places the origin in a private subnet, private link, VPC origin, or internal load balancer and connects only over a path the edge manages, which structurally reduces public IP, historical DNS, and direct port problems.
- Outbound tunnel
- An outbound tunnel makes only outbound connections from the origin to the edge network, removing the public inbound listener entirely, with the connector credential authenticating the origin connection.
- Origin authentication
- Origin authentication is the origin itself verifying, through mTLS, a deployment identifier, a signature, or an origin credential, that a request came from a specific account or deployment.
Inspect and protect requests before they reach the service — Review request and blocking records, tune protection rules and manage certificates and access controls.
The exposure audit splits into six areas
Use the checklist below only on assets the organisation owns or is explicitly authorised to audit. The six areas are scope and asset list, network and listeners, origin identity and request acceptance, host, TLS, and default response, management plane and public assets, and negative tests and operational evidence. Where the scope of APIs and endpoints is unclear, reconcile DNS, LB, serverless, and runtime routes through the API inventory operating document first.
Area | Checks |
|---|---|
| Scope and asset list | Is the audited scope of services, environments, domains, cloud accounts, and networks fixed? Does it include staging, preview, test, and legacy as well as production? Are current A, AAAA, and CNAME records collected? Are old and pending-removal DNS records and migration history reviewed? Are all public IPv4 addresses on VMs, load balancers, ingress, gateways, and firewalls identified? Are global IPv6 and dual-stack settings checked separately? Are public LB DNS names and backend service endpoints identified? Are PaaS, serverless, and object storage default domains identified? Are origin aliases and preview, beta, and legacy hostnames identified? Are the names in the certificate inventory and SANs identified? Does each service have a named business and technical owner? |
| Network and listeners | Has the need for a public IP on the origin been reviewed? Has a move to private subnet, private link, VPC origin, or tunnel been assessed? For a public origin, is inbound default-deny? Are only the provider's current edge source ranges, prefix lists, or service tags allowed? Are provider IP changes applied through a maintainable mechanism rather than a manual copy? Have all load balancer listeners been reviewed? Have the ports actually listening on the host OS been checked? Do container, Kubernetes service, or ingress configurations avoid exposing the node or VM directly? Is the health check source no broader than needed? Are unused HTTP, HTTPS, debug, and management listeners closed? Have 0.0.0.0/0 and ::/0 been reviewed separately? Are IPv6 flow logs or equivalent network evidence collected? |
| Origin identity and request acceptance | Have you distinguished whether the origin checks only "the provider network" or "our account and deployment"? Have you avoided assuming a shared edge IP allowlist is sufficient? Have you chosen mTLS, a per-deployment certificate, signed requests, a provider identifier, or an origin token appropriately? Is origin authentication applied consistently to every hostname and listener? Are requests without credentials kept from the application? Does a wrong credential produce a fixed deny response or a refused connection? Where a secret header is used, is it stored and rotated like a credential? Are header and certificate details kept out of access logs, traces, and error reports? Is there an owner and automation for certificate expiry, rotation, and revocation? Is the deployment order of edge and origin configuration changes defined? |
| Host, TLS, and default response | Does the origin TLS certificate match the expected service identity? Does the edge actually validate the origin certificate? Are unexpected host headers and SNI rejected at the default virtual host? Is a direct IP request that merely raises a certificate error not treated as access control? Does the same origin authentication apply to alternate hostnames? Does the default listener avoid returning application content or detailed errors? Do redirect responses avoid exposing internal hostnames or management paths? Does the HTTP-to-HTTPS listener also serve only approved edge sources? |
| Management plane and public assets | Are SSH, RDP, control panels, and database admin separated from the application origin? Are management interfaces kept off the public internet? Does management access carry user and device identity and an audit record? Is the emergency path kept from being used as an everyday bypass? Is the frontend JavaScript and configuration free of unnecessary origin addresses? Has the need to publish production source maps and debug assets been reviewed? Are endpoints and credentials kept out of public repositories, IaC output, and CI artifacts? Do status pages and operating documents avoid publishing internal origin and management addresses? Are endpoint information and secrets distinguished, so public endpoints are not managed as if they were secret? |
| Negative tests and operational evidence | Does the service work correctly through the official CDN and WAF path? Does a direct connection to the origin public IPv4 fail to return application content? Is the result the same over origin IPv6? Do old IPs, old hostnames, and alternate hostnames refuse the request? Do public LB and backend default endpoints avoid exposing the application? Are unapproved ports and management ports unreachable from outside? Are requests refused when origin authentication is missing or wrong? Is edge traffic from another account or deployment refused? Do refused direct requests appear in origin, firewall, and LB logs? Can edge-borne requests and refused direct requests be distinguished in the logs? Do deny responses avoid over-exposing framework, version, and internal hostname? Is the same verification repeated after DNS, CDN, LB, firewall, and certificate changes? Do temporary allow rules carry an expiry, an owner, and a reason? Is there a drift detection or periodic re-audit cadence? |
When the origin can be declared protected
Failing to find the origin address is not pass evidence. An address that happens not to be known and an origin designed to refuse direct requests are different things. Each of the eight items below is confirmed by a negative test.
Verification item | Pass criterion |
|---|---|
| Official edge path | A normal user request returns the expected function and response |
| Direct public IPv4 and IPv6 path | Refused at the TCP or TLS layer, or fixed-denied in front of the application. No real application content is returned |
| Old and alternate hostnames | Decommissioned, or enforcing the same network and origin identity policy as the official edge |
| Public LB and backend endpoint | Private, or not forwarding direct requests |
| Origin authentication | Requests with missing or wrong credentials, certificates, or identifiers are all refused |
| Management plane | Unreachable from the general internet and from the application origin path |
| Logging and observation | Approved edge traffic and direct access attempts are distinguishable and traceable |
| Re-verification after change | Negative test evidence is refreshed on every DNS, IP, CDN, LB, certificate, and firewall change |
The CDN and WAF are the front door
A CDN and a WAF are important edge controls, but they do not automatically lock every entrance of the building. The origin public IP, old DNS, other hostnames, IPv6, direct ports, management interfaces, and backend endpoints each have to be checked separately.
The most direct defence is removing the public route. Where a public origin has to remain, restrict network source and origin identity together. Address replacement, host validation, and secret headers are safer treated as supporting controls layered on top.
The final verdict comes from a negative test, not a settings screen. Only when you can prove the state where approved edge paths work and every other direct path fails to reach the application does the CDN and WAF become a control that is genuinely hard to bypass.
