A WAF at a rented edge fronts your public site — what does it stop for an attacker who has the origin's own address?
answer
- ask what the request must traverse
- the edge sees one route in
- the origin still answers its own address
- public certificate logs enumerate names
- state coverage as a path, not a service
basics
~20 sAn edge WAF judges only requests that arrive through the hostname it fronts. An attacker who addresses the origin directly never crosses it, so the honest claim is coverage of one path, not protection of the service.
solid answer
~50 sA request-judging control reaches a verdict on traffic that passes through it, and nothing else. When it sits at a rented edge, traffic gets there because the public hostname resolves to the provider's addresses — but the origin still has an address of its own and still answers requests sent to it with a `Host` header for the site. That attacker is past the control entirely, and no rule, paranoia level or tuning at the edge changes it. I would treat the origin address as discoverable rather than secret: Certificate Transparency logs publish every hostname a certificate was issued for, historical DNS records outlive a migration, and a mail or status host often still points at the same infrastructure. So the sentence I give a risk owner is conditional — requests arriving via the fronted hostname are judged, requests arriving by any other route are not — plus an inventory of what the origin answers on.
code
text · 10 lines# via the fronted hostname -> resolves to the edge, judged there
GET /login HTTP/1.1
Host: shop.example.com
...
# sent straight to the origin's own address, same Host header
# the edge is not on this path and never sees it
GET /login HTTP/1.1
Host: shop.example.com
...go deeper
Be ready to say plainly that a control only judges traffic that goes through it, and that an origin with its own reachable address is a second way in. Naming that gap out loud is what the question is testing.
Explain how traffic gets to the edge at all — the public hostname resolving to the provider's addresses — and therefore which changes on your side create a route that skips it: a second region, an exception hostname, a new API host.
Show the operating habit: assume the origin address is discoverable, keep an inventory of everything the origin answers on, and give the risk owner a conditional coverage statement rather than a reassuring one.
Own the framing that coverage is bought per path, so every new public entry point is a new purchase. Be able to say who funds and reviews that inventory and what you will not claim in a customer questionnaire.
## The claim a position can actually make A WAF, or any control that reaches a verdict on one request at a time, judges the requests that traverse it. That sounds too obvious to say, and it is the assumption most often broken in this design, because the phrase everyone uses is *the site is behind a WAF* — a sentence shaped like a property of the site. It is not a property of the site. It is a property of **one path to the site**. When the control is *ahead* — at a rented edge someone else operates — traffic reaches it because the public hostname resolves to that provider's addresses. Your origin (a load balancer, a server, a container ingress) has an address of its own and it has not stopped listening. Virtual hosting means it will serve the right application to anyone who supplies the matching `Host` header. So the same request that the edge would have scored, sent straight to the origin address, arrives unjudged. ## Why the origin address is not a secret Plan on the address being known, because every route to it is cheap: - **Certificate Transparency**: every publicly trusted certificate is logged with the hostnames it covers, so subdomains nobody advertised are enumerable, and one of them frequently resolves to the origin. - **Historical DNS**: records from before the edge was adopted are archived by third parties and do not expire from anyone's memory. - **Sibling hosts**: mail, status, staging, an old admin host — often the same infrastructure, often never moved behind the edge. - **The origin talking first**: an error page, a redirect to an absolute URL, a mail header, or an outbound connection the origin makes can carry its address. - **Scanning**: the address space is small enough to sweep for a TLS certificate or a response body that matches your site. The correct posture is not *they will never find it*; it is *assume they have it, and say what that means*. ## The other paths that miss the control The direct address is only the most obvious one. In a real estate the same failure arrives as: - a **second region** or a second public address stood up during a migration and never fronted; - an **admin or internal hostname** pointed straight at the origin because the edge broke a long upload or a long-lived connection, and the exception was never revisited; - an **API host** added after the edge was adopted, by a team that did not know the edge existed; - **non-HTTP ports** the origin listens on, which a request-judging control does not look at from any position. Each of those is created by your own side, not the attacker's, which is why the inventory has to be refreshed rather than written once. ## What this costs, and who pays it The price of a position is not only latency and money. It is the obligation to state coverage honestly and keep the statement true. From the chair that has to tell a risk owner what the control does **not** stop, the deliverable is two things: a sentence — *requests arriving via the fronted hostname are judged* — and a list of every address and hostname the origin still answers on, owned by a named person and reviewed when the estate changes. That is a standing review burden, and it is uncomfortable because it converts a reassuring sentence into a conditional one. Skipping it does not remove the exposure; it removes your knowledge of the exposure. Closing the direct path is a control on the origin's side of the network — who may address the origin at all — not something the WAF can do from where it stands. That is a different surface and a different team; from here the job is to name the gap, not to pretend the edge covers it. ## Get the direction of the claim right An alert firing at the edge proves that **a** request crossed the edge and was scored. It never proves that **all** requests do. Absence of alerts is equally silent: it is consistent with a quiet week, with a rule that no longer matches, and with traffic that stopped arriving at the edge at all. Coverage is a property of the path, so every claim about it has to name the path.
- How would an attacker find the origin's address in the first place?Assume it is findable. Certificate Transparency logs publish every hostname a certificate was issued for, historical DNS records survive the migration to the edge, a mail or status host often resolves to the same infrastructure, and an error page, a redirect or the origin's own outbound connections can leak it. Scanning for a matching certificate or response is cheap. Design as if the address is public.
- Who owns closing that path, and what do you owe the risk owner if it stays open?It is a control on the origin's side of the network — who is allowed to address the origin — not something a WAF can do from the edge. From your chair the deliverable is written: exactly what is judged (requests via the fronted hostname), what is not, and an inventory of every address and hostname the origin still answers on, with an owner and a review trigger when the estate changes.
- Does the same blind spot exist for a proxy you run inside your own network?Yes in kind — any position judges only what is routed through it. The difference is who creates the miss. With a proxy you run, the paths that bypass it come from your own routing and DNS changes, so you can find and fix them; with a rented edge ahead, the shape of the path is set by a provider's model and your origin's exposure is the part you still own.
A doorman covers the entrance he stands in. The building is only as covered as the doors that lead through him — the loading bay is not his problem, and saying the building has a doorman does not change that.
saying these in an interview costs you the question
- Says the site is protected because DNS points at the edge
- Assumes an attacker cannot discover the origin's address
- Treats a WAF as a property of the application, not of a path
- Promises a risk owner blanket coverage without naming the route
- Thinks tuning rules at the edge can cover a path that misses it