We run continuous security assessments at breka.ai. A lot of them start the same way: the customer points us at the application behind their firewall, and we find the door next to it.
In our latest batch, 33 percent of the applications we attacked had an origin server reachable directly, with no firewall in the way. The CDN and the WAF were doing their jobs. The problem was that the application was also listening somewhere else.
This is the fifth finding in our field series, after endpoints that skip authentication, exposed internal tools, forgotten staging environments, and secrets in JavaScript bundles. This one is about the shield itself: real, and the application is also standing outside it.
What origin exposure is
Origin exposure means the server that actually runs your application is reachable on the public internet, so an attacker can talk to it directly and skip the firewall entirely. MITRE tracks the underlying pattern as CWE-693, Protection Mechanism Failure: the protection exists, but it does not cover the whole surface.
A CDN or WAF works by sitting in front of your origin. Traffic goes to the firewall first, the firewall filters, the good traffic is forwarded. That only works if the origin refuses to talk to anyone except the firewall. When the origin answers direct connections, the firewall is decoration.
What an attacker does with it
Finding the origin is not hard. DNS history services, certificate transparency logs, and old DNS records all remember the IP addresses your domain used before the CDN arrived. Then it is one request:
curl -k https://203.0.113.7 -H "Host: app.example.com"
Real findings from recent engagements, anonymized:
- An analytics database answered unauthenticated queries on a direct origin IP. The company's Cloudflare sat in front of the marketing site and the app, but the database listened on its own port on the same server, and anyone who found the IP could query it and read its telemetry.
- An API gateway's origin was directly reachable, bypassing the WAF entirely. Every rule the team had written, rate limits, IP blocks, bot detection, applied only to traffic that chose to go through the front door.
- A non-production gateway was reachable over plaintext HTTP, no encryption, no firewall, while production sat behind the full stack.
- A company's origin IPs were public, and the origin served the application and the API directly. The CDN was a mirror, not a gate.
- A QA estate ran on a bare host with no CDN and no WAF at all, while production had both. Same code, fewer guards, one hostname away.
- An admin domain published private internal addresses in public DNS, handing an attacker the company's internal addressing scheme to aim at.
The pattern is always the same. The team secured the front door and forgot the house has other doors.
Worth saying: in most of these companies, the application itself held up under direct testing. The firewall was doing its job for the traffic that reached it. The problem was the traffic that did not.
Why this is a real problem
A WAF is where teams put their trust: rate limiting, bot detection, IP reputation, virtual patching for known CVEs. Bypassing it is not a sophisticated attack. It is a routing decision. The attacker sends the same malicious request to the IP instead of the domain, and every control the team paid for simply never sees it.
The consequences depend on what the origin serves. If the origin is the application, the bypass is total: the attacker is talking to production with no filtering. If the origin is a database or an admin interface, it is worse, because those were never meant to be public at all and often carry weaker authentication, or none.
There is a second-order problem too. When we find an exposed origin, we usually find that the team's monitoring does not see it. The firewall logs are clean, because the firewall was not involved. The incident never happened, as far as the dashboards are concerned.
Why origins end up exposed
The reason is usually the migration itself. A team moves to a CDN, updates DNS, and considers the job done. The origin still listens on all interfaces, because that is the default, and nothing in the deployment told it to stop. The old IP stays in DNS history and certificate logs forever.
Sometimes it is the opposite: a new service is deployed on the same infrastructure, points directly at the origin, and nobody remembers to route it through the firewall. Or a vendor, a contractor, a monitoring tool, gets the origin IP to bypass the CDN for performance, and that exception becomes permanent.
And occasionally the team knows and accepts it, on the theory that the origin IP is secret. It is not. IP addresses are not secrets. They are enumerated, archived, and shared.
How to fix origin exposure
The fix is to make the origin refuse direct connections. Four steps.
Step one. Find your origins. Enumerate every IP your domains have ever resolved to, from DNS history and certificate transparency logs. Then try to reach each one directly, with your domain in the Host header. Anything that answers is exposed. This is exactly what an attacker does, and it takes an afternoon.
Step two. Restrict the origin to the firewall. Configure the origin's network or host firewall to accept traffic only from your CDN or WAF provider's published IP ranges. Everything else gets no response. The origin becomes unreachable except through the front door.
Step three. Require a shared secret. Have the firewall send a header or token that the origin verifies, so even a request that reaches the origin directly is rejected unless it came through the firewall. Defense in depth: if the IP allowlist drifts, the secret still holds.
Step four. Re-test after every infrastructure change. Origins reappear the same way they appeared the first time: a migration, a new vendor, a shortcut. The check has to return when the infrastructure changes, and infrastructure changes constantly. That is how we work.
Frequently asked questions
What is an origin server?
The origin is the server that actually runs your application and holds your data. A CDN or WAF sits in front of it, caches content, and filters traffic. When someone says "bypass the CDN", they mean reaching the origin directly and skipping that filtering.
How do attackers find my origin IP?
DNS history services record every IP your domain has ever resolved to, including the ones from before you added a CDN. Certificate transparency logs, old DNS records, and even error messages from your own services can reveal it. IP addresses are not secrets.
Is a WAF enough to protect my application?
Only if the origin refuses direct connections. A WAF protects the traffic that reaches it. If the origin answers on its own IP, an attacker routes around the WAF and every rule on it. The WAF is one layer, not a perimeter.
How do I check if my origin is exposed?
List every IP your domains have resolved to, then request each one directly with your domain in the Host header. If it answers with your application, it is exposed. Then check your database, admin, and monitoring ports on the same IPs.
What is the fix for an exposed origin?
Restrict the origin's firewall to accept traffic only from your CDN or WAF provider's IP ranges, and verify a shared secret header on every request. Then re-test after every infrastructure change, because origins reappear with every migration and new vendor.
The point
We keep finding exposed origins because teams secure the domain and forget the IP. The firewall is real, the rules are real, and the application is also standing next to them, answering anyone who asks.
If you want to know where you stand, it takes an afternoon. Find the IPs your domains have ever used, and ask each one directly. If your application answers, that is the finding.
And if you would rather have someone do the enumeration, the probing, and the re-testing every time your infrastructure changes, that is exactly what we do.
Related reading: Your Internal Tools Are Not Internal — the dashboards that often sit on those same exposed origins. And The Environment Everyone Forgets to Defend — the non-production hosts that usually have no WAF at all.