In architectures with WAF/CDN, the implicit design is simple: all “real” traffic must enter through the perimeter layer, be inspected, and only then reach the origin (ALB, API Gateway, App Service, etc.). Origin IP Bypass breaks that contract when the public IP of the origin is exposed and can be reached from the Internet. At that point, the WAF can keep “working” and billing, but the attacker is no longer forced to go through it.
The tricky part is that it usually doesn’t fail due to a sophisticated vulnerability, but due to small operational decisions: a forgotten subdomain, a rushed DNS change, a revealing header, or an overly permissive Security Group/NSG. The impact is not theoretical: bots and automated attackers look for exactly these gaps because they turn an expensive defense into an option.
What went wrong: the bypass doesn’t attack the WAF, it goes around the architecture
The typical scenario is this: you publish an application behind CloudFront/Azure Front Door/Cloudflare with WAF and well-tuned rules. The team trusts that the origin will only receive “filtered” traffic. However, the origin (an Application Load Balancer, an API Gateway or a direct HTTP endpoint) still has a public IP or a resolvable name and, worse, is accessible from 0.0.0.0/0. The attacker doesn’t “break” the WAF: they simply stop using it.
In production this shows up with concrete consequences: CPU spikes in the backend while the WAF dashboard looks calm; rate limiting that seems to have no effect; and an increase in 5xx errors that doesn’t correlate with the traffic observed on the CDN. In real incidents, the first symptom is often a “mysterious” layer-7 DDoS or aggressive scraping that, supposedly, your WAF already blocked.
There is an operational detail that makes the problem worse: many teams validate security by looking only at the “correct” flow (client → CDN → origin). But the bypass is validated by attacking the “forbidden” flow (client → origin direct). If that route exists, the rest of the controls are partial by definition.
How the origin IP is discovered in corporate environments (and why it happens)
Discovering the real IP of the origin doesn’t require magic; it requires patience and lateral signals. In large organizations it is common for remnants to exist: test subdomains, endpoints inherited from migrations, or old DNS records in caches and external providers. In an internal pentest, DNS enumeration and certificate review are often enough to find an unintended back door.
The most frequent vectors fit day-to-day life in a company:
- Forgotten or parallel subdomains: an
api-old.company.comthat points directly to the ALB or to a “temporary” backend that ended up being permanent. - DNS history: provider changes (from direct ALB to CloudFront, for example) leave traces; attackers query historical sources or resolve names that previously pointed to the origin.
- Leaks in headers or responses: responses that reveal infrastructure or internal routes; sometimes a backend returns redirects, hostnames, or inconsistent values that help with triangulation.
Each of these points usually appears due to real friction: go-live rush, different teams managing DNS and network, and the false sense that “if the main domain is behind the CDN, that’s it”. In incidents, the bypass often enters through a subdomain that isn’t even in the application inventory.
A very concrete consequence: if the attacker discovers the origin, they can launch brute force, exploitation of heavy endpoints, or API abuse directly against the ALB/API Gateway. It is common for the WAF to have rules for path traversal, SQLi, or bots, but the direct origin will never see them.
The most expensive configuration mistake: open rules toward the origin
The classic pattern is a Security Group/NSG that allows HTTP/HTTPS from anywhere because “the WAF/CDN already protects it”. That is exactly what enables Origin IP Bypass. In AWS, for example, an internet-facing ALB with a security group that allows 443 from 0.0.0.0/0 will still be accessible even if CloudFront is in front. In Azure, a backend behind Front Door without equivalent restrictions ends up in the same situation.
In companies this appears for practical reasons: it is enabled temporarily for a test, for an external partner, for monitoring, or because nobody wants to maintain allowlists of IP ranges. The problem is that the “temporary” becomes permanent, and the attacker only needs an exposure window. Also, when the origin receives direct traffic, your observability fragments: part of the traffic is seen in CDN/WAF logs and part only in backend logs, complicating incident response.
Early signals that often go unnoticed:
- Traffic at the origin with unexpected Host: requests that don’t carry the public domain’s
Host, or that use the ALB/API DNS name. This usually indicates direct access or scanning. - “Impossible” client IP distribution: if you expect to see only CDN IPs reaching the origin, but residential IPs or random cloud provider IPs appear, there is a bypass or a parallel path.
Operationally, each bullet translates into clear actions: review ALB/API logs for Host, SNI and UA patterns; and compare the source IP list with the allowed ranges from the CDN provider. If that comparison doesn’t close, the bypass is no longer a hypothesis: it’s a fact.
How to do it in practice: close the bypass with verifiable controls
Effective mitigation is not “adding more rules to the WAF”, because the bypass avoids it. Mitigation is eliminating the public reachability of the origin or restricting it strictly so that only the CDN can talk to it. The decision will depend on your platform and whether you can operate without a public IP.
Concrete actions that work in real environments:
- Restrict the origin to the CDN’s IP ranges: in AWS, adjust the ALB Security Group to allow 443 only from CloudFront ranges (if it applies in your design) or from controlled components; in Azure, the equivalent with NSG/Firewall so the backend only accepts expected traffic.
- Native WAF integration on the load balancer: if your origin is an ALB, associating AWS WAF to the ALB reduces the CDN “single point”; if someone reaches the ALB, there is still inspection. In Azure, the equivalent pattern is bringing the control to the layer that actually receives traffic.
- Remove the origin’s public IP with PrivateLink: use AWS PrivateLink/Azure Private Link so the backend is private and transit to the origin does not depend on a public IP reachable from the Internet.
The key is verification, not intention. Validate with direct tests: try to connect to the origin IP/DNS from an external network. If it responds, the bypass is still open. In AWS, also verify that the ALB is not exposed by mistake (internet-facing scheme) and that the Security Group does not have broad inbound. In Azure, verify that the backend has no alternative public exposure via inherited endpoints or overly general rules.
An additional control that helps detect allowlist failures: instrument alerts when the origin receives traffic from IPs outside the expected set (CDN ranges, corporate NATs, etc.). In real incidents, this alert reduces time to detection from days to minutes.
Recommendations for corporate environments
Origin IP Bypass appears when the origin maintains a public route parallel to the CDN/WAF. You don’t need the WAF to “fail”; it’s enough for the attacker to find the real IP of the ALB/API Gateway via forgotten subdomains, DNS history, or signals in headers, and to be able to connect because Security Groups/NSGs allow 0.0.0.0/0.
The measures that really close the problem are architectural and network-based: restrict the origin so it is only reachable by the expected perimeter, bring controls (WAF) to the layer that receives traffic if exposure is unavoidable, and prefer designs without a public IP using PrivateLink when the platform allows it. Operationally, the discipline is to verify: test direct access to the origin from outside and monitor any source IP that does not correspond to the CDN.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.