Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: API WAF protection is only as complete as the API inventory behind it, according to LEVO. In fast-changing environments with shadow, deprecated, GraphQL, and gRPC endpoints, static documentation leaves enforcement gaps that perimeter tuning cannot fix.
NHIMG editorial — based on content published by LEVO: API WAF failures often begin long before traffic is inspected
Questions worth separating out
Q: What breaks when API inventory is incomplete in front of a WAF?
A: The WAF only protects the APIs it knows exist, so incomplete inventory creates unprotected endpoints, missing schema checks, and uneven rate limiting.
Q: Why do undocumented APIs create security risk even if the WAF is deployed?
A: Undocumented APIs sit outside the policy boundary used to configure the WAF, so they can receive traffic without inspection or alerting.
Q: How should security teams verify that WAF coverage is actually complete?
A: Start with external discovery, not policy documents.
Practitioner guidance
- Implement runtime API discovery Use live traffic analysis to identify active endpoints, versions, and consumers, then compare that map with documentation and gateway configuration on a continuous basis.
- Bind WAF scope to observed production behaviour Configure protection based on verified runtime usage rather than OpenAPI files, wiki pages, or release notes that may lag behind deployment.
- Track shadow and zombie endpoints separately Create distinct workflows for undocumented APIs and deprecated APIs still receiving traffic, because they represent different governance failures and require different remediation paths.
What's in the full article
LEVO's full analysis covers the operational detail this post intentionally leaves for the source:
- How API Inventory derived from live traffic is used to reconcile documented APIs with production behaviour
- How API Discovery, API Monitoring, and API Protection fit together in an operational workflow
- Why shadow, zombie, GraphQL, and gRPC endpoints break static WAF assumptions in different ways
- How runtime scope alignment changes enforcement decisions for APIs already in production
👉 Read LEVO's analysis of why API WAF security depends on runtime inventory →
API inventory drift: why WAF coverage misses live endpoints?
Explore further
06/09/2026 3:45 pm
API inventory drift is a governance failure, not a tuning problem. The article’s central point is that perimeter controls inherit the quality of the asset map they are given. If the organisation treats inventory as a document instead of a runtime control, the WAF becomes selective by default. That is a governance model problem, and it aligns with NIST Cybersecurity Framework 2.0 thinking around asset visibility and protection scope. Practitioners should treat runtime inventory as part of control design, not as a cleanup exercise.
A question worth separating out:
Q: How should organisations govern API security when documentation lags production?
A: They should treat runtime discovery as the source of truth, then use inventory to drive monitoring, policy assignment, and incident response. Documentation still matters, but only as a design reference. The operational control is continuous reconciliation between what engineering intended and what is actually serving traffic.
👉 Read our full editorial: API WAF security depends on runtime inventory, not static docs
