API discovery methods compared: Which finds shadow, zombie, and undocumented APIs?

In this guide, we compare five API discovery methods – API gateways, network traffic analysis, code repositories, runtime monitoring, and DAST-driven discovery – to show how each contributes to API visibility and discuss the limitations of each approach.

Most importantly, we explain why complete API visibility requires combining these methods into a continuous system – and why discovery alone is not enough without validation.

What are API discovery methods and why do they matter?

API discovery methods are the various techniques used to identify APIs across your environment – from source code to runtime traffic to live applications.

They exist and are needed because modern applications are no longer monolithic. APIs are created across distributed teams, deployed continuously, and often exposed in ways that are not centrally tracked. Most APIs are not visible at the user interface layer – they exist beneath the surface, forming a much larger hidden attack surface.

This leads to:

• Shadow APIs created outside formal processes
• Zombie APIs that remain active after deprecation
• Gaps between documented specifications and real runtime behavior

Each API discovery method provides a different lens on this problem. Some focus on infrastructure. Others look at code, traffic, or application behavior. But none provides complete API visibility on its own.

It is also important to distinguish between discovery and inventory management. Discovery identifies what exists at a specific point in time, while inventory management stores and organizes that information to ensure that the overall view remains accurate as APIs change.

This is why comparing API discovery methods is essential – not just to understand what you can find, but to understand what you are likely missing.

The five main API discovery methods

There are five primary API discovery methods used in modern AppSec programs. Each contributes to API inventory and visibility, but each on its own also has blind spots that might give attackers an opening.

Discovery using API gateways

Gateway-level discovery extracts API definitions directly from API management platforms. 

It is often the simplest method to implement because it uses existing infrastructure and provides structured, well-documented APIs that are already under governance. It is effective for:

• Identifying officially managed APIs
• Retrieving accurate specifications and schemas
• Mapping ownership and access controls

However, this method has structural limitations. It only covers APIs that pass through the gateway, which means it misses:

• Shadow APIs deployed outside governance
• Internal service-to-service APIs
• Deprecated APIs still active in production

This creates a clean but incomplete inventory – one that can give a misleading sense of control while leaving large parts of the attack surface unmonitored.

Discovery using network traffic analysis

Network traffic analysis discovers APIs by observing real API calls in transit.

By analyzing HTTP traffic, this method reveals APIs that are actively being used, including undocumented endpoints that would otherwise remain hidden. It is effective for:

• Detecting shadow APIs in real-world usage
• Understanding how APIs are actually consumed
• Identifying externally exposed endpoints

However, it is inherently limited to services that are currently active. It cannot reliably detect:

• Dormant or rarely used APIs
• Newly deployed APIs with little traffic
• APIs that are not visible at the monitored network layer

It also introduces some operational complexity, often requiring coordination with network or platform teams. As a result, coverage improves, but completeness is still out of reach.

Discovery using code repositories

Code repository discovery analyzes source code to identify API definitions before deployment.

This approach shifts API discovery earlier in the lifecycle, making it easier to catch issues before they reach production. It is effective for:

• Discovering APIs during development
• Identifying undocumented or internal endpoints
• Enriching API schemas with source-level context

However, code does not always reflect the full reality. This method cannot account for:

• Drift between code and deployed behavior
• Third-party or dynamically generated APIs

Detection of deprecated or “zombie” APIs is possible in some cases, but typically requires correlation between repository data and deployed environments. In fast-moving environments, the gap between code and production can be significant, which makes this method necessary but insufficient on its own.

Runtime and Kubernetes discovery

Runtime discovery observes APIs at the infrastructure level, such as within containerized or Kubernetes environments.

This method provides deep visibility into internal, service-to-service (“east-west”) APIs that are otherwise invisible to external tools. It is effective for:

• Discovering internal and east-west APIs
• Mapping microservices interactions
• Capturing real runtime behavior

However, it comes with higher operational overhead and requires cross-team coordination. Like traffic analysis, it is limited to what is currently running, not the full lifecycle of APIs. This means it adds another layer of visibility, but still not completeness.

DAST-driven API discovery

DAST-driven discovery identifies APIs by analyzing running applications during dynamic application security testing.

As the scanner interacts with the application, it uncovers API endpoints used by front-end logic and downstream services. It can then test those APIs for vulnerabilities within the context of reachable application workflows.

DAST-driven API discovery is effective for:

• Discovering APIs exposed through application behavior
• Identifying downstream and hidden APIs
• Validating APIs for real, exploitable vulnerabilities

Like any dynamic testing approach, coverage is constrained by what the scanner can access and execute. Its effectiveness depends on factors such as authentication handling, session management, and the ability to follow real workflows. This limitation means it may not fully identify:

• Isolated internal APIs
• APIs without user-facing entry points
• APIs requiring complex multi-step interactions or specific preconditions

Standalone or unreferenced deprecated endpoints – a common form of zombie API – may also be missed if they are not linked to application behavior and exercised during scanning.

The main strength of DAST-driven discovery is its ability to connect identified endpoints directly to real-world risk validation. In practice, this method is most effective when combined with other discovery methods to improve overall coverage.

API discovery methods compared

Each API discovery method contributes to visibility in a different way. The table below compares these methods based on coverage, operational complexity, and their ability to support real security outcomes.

Note that while some runtime tools can surface anomalous behavior or unexpected API activity, they do not directly validate exploitability in the way dynamic testing can.

Why no single API discovery method is enough

The limitations of each individual method are inherent to how those approaches work:

• Gateway discovery is limited by governance boundaries
• Traffic and runtime methods are limited by current activity
• Code analysis is limited by what is defined, not what is running
• DAST is limited by what is reachable through application behavior

Relying on any single method leaves blind spots that attackers can exploit.

Attackers do not rely on documentation or approved inventories. They probe for exposed endpoints, forgotten APIs, and inconsistencies between environments. Unknown and unmanaged APIs are often easier to exploit because they are less likely to be tested or monitored.

Relying on a single API discovery method or an incomplete subset of methods results in incomplete API visibility and increased risk.

Most tools don’t help with this fragmentation. They either focus on one method or combine several without integrating them into a cohesive system. The result is more data, but not more security.

Connecting API discovery to API security: The missing link

Even when organizations improve API inventory, many stop at discovery. They build lists of APIs but do not consistently validate their security. This creates a dangerous gap.

Discovery is typically point-in-time, but modern APIs can change continuously – new endpoints are deployed, existing ones evolve, and deprecated ones remain exposed. Without ongoing inventory management and validation, API visibility quickly becomes outdated.

More importantly, discovery on its own does not answer the most critical question: Which APIs are actually vulnerable and exploitable?

This is where a DAST-first approach becomes essential as a validation layer. Dynamic testing evaluates APIs in their running state to identify vulnerabilities that can be exploited in real-world conditions. Instead of theoretical findings, it provides validated results that security and development teams can act on.

This shift – from visibility to validation – is what transforms API discovery into effective API security and assurance.

A unified, multilayered approach to API discovery and security

Achieving full API visibility requires combining multiple methods – but more than that, it requires those methods to work together as part of a continuous system.

Invicti provides this through a multilayered API discovery approach that integrates:

• Web application scanning
• Code repository analysis
• API gateway integration
• Network traffic analysis
• Runtime and infrastructure visibility

These methods are normalized and correlated into a unified API inventory, where endpoints discovered across different sources are deduplicated and enriched into consistent, scan-ready representations. This reduces the need for manual reconciliation across tools and ensures more complete coverage.

Just as importantly, it enables a continuous discovery-to-testing pipeline:

• APIs are discovered across multiple layers
• They are normalized into a consistent inventory
• They are immediately tested using API DAST
• Where applicable, vulnerabilities are validated with proof of exploitability for supported vulnerability classes

This approach closes the gap between visibility and security. It ensures that every discovered API is not just known, but actively assessed for real risk.

Learn more about API discovery on the Invicti Platform.

Extending discovery into continuous security posture management

Discovery and testing are critical, but APIs are constantly changing, and security programs must adapt in real time.

By combining multilayered discovery with continuous DAST-based validation and centralized visibility, organizations can move toward continuous API security assurance.

This includes visibility across both pre-production and production environments to help teams identify APIs earlier in development while ensuring that deployed APIs are continuously tested. For example, APIs identified in code repositories can be surfaced earlier in CI/CD workflows, while the same endpoints are continuously validated after deployment through dynamic testing.

In practice, this means:

• Maintaining a continuously updated API inventory
• Validating APIs based on real runtime exposure
• Prioritizing vulnerabilities using verified data
• Tracking risk across the entire SDLC

This connects visibility, validation, and prioritization into a single system that turns API discovery into a core part of application security posture management.

How to choose the right API discovery approach

Choosing the right API discovery methods depends on your organization’s maturity, architecture, and operational constraints. A practical approach is to build in layers:

• Start with low-friction methods such as API gateway integration and DAST-driven discovery to establish baseline visibility
• Add code repository discovery to shift visibility earlier into development workflows
• Introduce traffic and runtime discovery as your program matures and cross-team coordination improves

It is also important to consider organizational realities:

• Some methods depend on developer access and code visibility
• Others require network or platform team involvement
• Advanced methods introduce operational complexity

The goal is not to adopt every method at once, but to progressively increase coverage and move toward complete API visibility and continuous assurance over time.

See how multilayered API discovery works in practice

API discovery is not just about building an inventory. It is about understanding your real attack surface and continuously validating its security.

A multilayered approach combined with DAST-based testing provides the most accurate and actionable view of your API attack surface and associated risk.

Schedule a demo to see how Invicti delivers continuous API discovery and security testing.