How should security teams discover APIs that bypass gateways and WAFs?

Why This Matters for Security Teams

APIs that bypass gateways and WAFs often become invisible trust paths inside production. That matters because discovery gaps are not just a coverage issue, they are a control failure: security teams can enforce policy at the edge while unmanaged services accept authenticated or even unauthenticated requests deeper in the environment. The result is inconsistent enforcement of authentication, rate limiting, logging, and data handling.

Current guidance from the NIST Cybersecurity Framework 2.0 supports asset visibility and continuous risk management, but the operational challenge is that API sprawl rarely appears in a single console. Teams also miss shadow or forgotten services when discovery is tied only to gateway logs, because direct-to-service traffic, east-west calls, and internal integrations may never touch the perimeter controls.

For security leaders, the real issue is governance as much as detection. An API that is live but absent from inventory cannot be reviewed for ownership, threat modeling, authentication strength, or exposure to sensitive data. In practice, many security teams encounter this only after an internal incident review reveals that the bypass path was already in production for months.

How It Works in Practice

Effective discovery uses multiple lenses at once. Traffic analysis shows what is actually being called, service mapping reveals where the endpoint lives, and inventory reconciliation highlights what exists but is not formally approved. That combination is stronger than perimeter monitoring alone, because gateway and WAF telemetry only covers a slice of the architecture.

Teams usually start by comparing observed network flows, DNS records, service mesh telemetry, cloud load balancer logs, and application tracing data against the authoritative API register. They then validate whether each endpoint is externally exposed, reachable only internally, or callable by machine identities such as service accounts, workloads, or agents. When an API is found outside the approved path, it should be triaged for ownership, data classification, authentication method, and authorization model before it is accepted into production governance.

A practical workflow often includes:

• Scanning cloud and on-premises assets for listening services and public routes.
• Correlating traffic from SIEM, service mesh, and observability tools to identify direct calls.
• Reconciling discovered endpoints with source-of-truth inventories and CI/CD records.
• Checking whether the API is protected by mTLS, token-based auth, or network-only trust.
• Confirming whether logging, alerting, and abuse detection are active for the bypass path.

Best practice is evolving toward continuous discovery rather than periodic audits, especially in containerized and microservice-heavy environments. NIST SP 800-207 is useful here because zero trust thinking pushes teams to verify each request path instead of assuming that traffic behind the gateway is inherently safe. These controls tend to break down when service ownership is unclear across multiple cloud accounts because discovery results cannot be reconciled to a single accountable team.

Common Variations and Edge Cases

Tighter discovery often increases operational overhead, requiring organisations to balance stronger visibility against engineering friction and alert noise. That tradeoff is real in large platforms, especially where ephemeral services, serverless functions, or internal-only APIs change faster than governance records can be updated.

Some environments also create false confidence by treating WAF or API gateway deployment as proof of coverage. That assumption is weak when traffic moves through private links, east-west service traffic, partner integrations, or direct IP access. In those cases, endpoint discovery must include cloud control plane data, runtime telemetry, and application-level logs, not just perimeter devices.

There is no universal standard for discovery completeness yet, but current guidance suggests prioritising endpoints that handle sensitive data, privileged operations, or machine-to-machine authentication. The CISA Zero Trust Maturity Model reinforces the need to verify access paths continuously, while the OWASP API Security Project is helpful for understanding how undiscovered or weakly governed APIs become attack surfaces. The edge case that trips teams most often is a legacy service kept alive for one internal workflow, because it sits outside standard deployment pipelines and escapes both gateway policy and normal asset review.

Related resources from NHI Mgmt Group

• How should security teams discover AI agents that bypass the IdP?
• How should security teams handle socially engineered email attacks that bypass secure email gateways?
• How should security teams respond when they discover stolen OAuth or session tokens?
• How should security teams reduce the risk of SSO bypass attacks?