A Web Application Firewall can inspect only the requests that reach it. If a public application also accepts traffic through an unprotected server address, load-balancer endpoint, or alternate hostname, that route can leave a gap in the intended WAF coverage. The practical check is to map every path to the application, restrict unintended direct access, and verify both the permitted and denied routes.
For IT directors, application owners, and MSPs, the useful deliverable is a coverage record: which entry points were tested, where policy was enforced, what evidence was captured, and who owns any exception. A working website and an active WAF dashboard do not establish that every application request passes through the control.
Define the origin and the protection boundary
The origin is the server or service that supplies the application behind a reverse proxy or other front-end delivery layer. A WAF may sit at that front layer, at a load balancer, or elsewhere in the application path. Start by locating the actual inspection point in your architecture; an alternate address is not automatically a bypass if the same required inspection still applies there.
Changing public DNS to point at a protected endpoint does not, by itself, remove other ways of reaching the origin. NIST's Guidelines on Firewalls and Firewall Policy explains the broader architectural issue: an additional entry point without the appropriate filtering can admit traffic that the main entry point would block.
Build a route inventory with the application owner
Use hosting records, deployment configuration, DNS records, and the application diagram together. OWASP's network infrastructure configuration testing guidance calls for mapping the infrastructure and maintaining the application's required ports under change control. The following worksheet applies that principle to WAF coverage.
| Route | What to establish | Evidence to retain |
|---|---|---|
| Normal customer hostname | Which WAF policy inspects its requests? | Destination, policy identifier, and an observed test event. |
| Origin or load-balancer endpoint | Can an unapproved internet client reach the application directly? | Access restriction and a controlled external test result. |
| API, administrative, or alternate hostname | Does it follow the intended protection path or a separately approved control? | Route owner, applicable policy, and any documented exception. |
| Secondary address, listener, or standby environment | Does the restriction cover IPv4, IPv6, additional ports, and failover where present? | Applicable configuration and the checks actually completed. |
A route marked “unknown” is unfinished work. Do not count it as protected simply because it belongs to the same application or hosting account.
Make the approved path enforceable
Have the hosting and security teams agree which systems may reach the origin and how that permission is enforced. Depending on the architecture, the answer may involve private connectivity, tightly scoped network rules, or an authenticated connection from the approved front end. Confirm the available mechanisms with the platform owner rather than assuming a particular WAF product supplies them automatically.
NIST recommends blocking traffic that is not expressly permitted by policy. Apply that principle carefully: identify legitimate health checks, integrations, administration, and recovery access before changing rules. Give each necessary exception a purpose, owner, restriction, and review date. A broad temporary opening should not become the permanent recovery plan.
Test the boundary without attacking the application
Agree on targets, test sources, timing, expected outcomes, and stop conditions first. NIST SP 800-115 provides a foundation for planning security assessments and handling findings. For this coverage check, use approved harmless requests and synthetic test data; exploit payloads are unnecessary.
- Verify normal use. Confirm an agreed customer workflow succeeds through the intended WAF path.
- Exercise the approved policy check. If supported, coordinate a narrowly scoped temporary test rule with the WAF operator. Confirm the harmless test request produces the expected decision and event.
- Check unintended direct routes. From an authorized external test location, have the tester verify that inventoried origin routes cannot serve the application around its required protection. Use the application's correct hostname and TLS context so an unrelated default-site response does not create false confidence.
- Recheck legitimate dependencies. Confirm health checks and agreed integrations still work, then remove temporary test settings.
A timeout alone does not prove that the intended rule denied a request. A generic error page may come from the application rather than the WAF. Record where enforcement occurred and investigate ambiguous results. Mark untested routes explicitly.
Keep evidence that survives the next change
For each test, retain the time, environment, route, source, expected result, observed result, relevant policy, and sanitized log reference. Correlate records where available; do not expect a request stopped at a network boundary to appear in application logs. Keep credentials and sensitive request data out of the worksheet.
Assign follow-up owners for gaps and repeat the affected checks after changes to hosting, DNS, listeners, network rules, WAF placement, or failover. The acceptance question is specific: can the team show that each in-scope route either passes through its required protection or is restricted by an explicitly approved alternative?
Bring the route map to the coverage discussion
Network Box USA's managed WAF service includes request filtering, application policy, tuning, and reporting. Origin restrictions, hosting changes, testing, and exception ownership should be agreed for the actual environment. To review those responsibilities and your application coverage, contact our team with the route map and any unresolved test results.