API documentation is useful until it stops matching reality.
A team might maintain accurate OpenAPI specifications, review routes during development, and follow a release process. Yet a few months later, the production environment may contain endpoints that nobody remembers documenting.
Perhaps an older API version is still receiving requests. Maybe a temporary endpoint became part of a permanent workflow. Or a new microservice introduced routes that never made it into the central inventory.
These situations are easy to overlook because the application can continue working normally. The problem becomes apparent when a security team tries to answer a basic question: Do we actually know every API endpoint exposed by our applications?
The gap between documented APIs and running APIs
Traditional API inventories are often built from source code, OpenAPI specifications, gateway configurations, and developer-maintained records. Each source provides useful information, but none necessarily represents every endpoint currently receiving traffic.
Consider an application with three API versions. The development team has moved most clients to the latest version, but a legacy integration still uses an older endpoint. That endpoint may remain accessible long after the documentation has been updated.
This creates an inventory gap.
The same problem can occur with shadow APIs, undocumented internal services, and endpoints introduced during rapid development. These routes are not automatically vulnerable, but they can become security blind spots when teams don't know they exist.
How runtime API discovery works
Runtime API discovery approaches the problem from a different direction. Rather than relying exclusively on what developers intended to deploy, it examines API traffic observed at runtime.
A typical workflow includes three stages.
1. Discover active endpoints
The system analyzes available application traffic to identify observed API routes and related request characteristics. The results depend on traffic visibility, integration coverage, and the discovery method used.
2. Compare observed behavior with the existing inventory
Security teams can investigate endpoints that are missing from documentation, older versions that remain active, and differences between expected and observed API behavior.
3. Prioritize findings
An unfamiliar endpoint is not necessarily a security issue. Teams need to determine whether it is expected, who owns it, whether it should remain accessible, and what security controls it requires.
The goal is not simply to produce a longer API list. It is to build an inventory that reflects the environment closely enough to support meaningful security decisions.
What should developers investigate first?
When reviewing a runtime API inventory, I would start with a few practical questions.
Are deprecated endpoints still receiving legitimate or unexpected traffic?
Are undocumented routes accessible from outside their intended network?
Do observed request parameters differ from the documented schema?
Are authentication and authorization controls consistent across API versions?
Can every discovered endpoint be associated with an owner and a business purpose?
These questions help separate normal application changes from findings that require further investigation.
For example, an endpoint that accepts an undocumented parameter might indicate a documentation gap. An endpoint that exposes sensitive functionality without the expected authorization checks requires a more urgent review.
Context matters, so discovery findings should be validated before teams make changes that could disrupt production applications.
Choosing a runtime API discovery approach
Not every discovery implementation works in the same way. Before choosing a solution, it is worth evaluating several practical considerations.
Traffic coverage: Which gateways, proxies, environments, and application routes can the solution observe?
Deployment requirements: Does it require agents, SDKs, application code changes, or configuration changes at the traffic layer?
Inventory quality: Can the output distinguish endpoints, methods, API versions, and relevant behavioral differences?
Risk prioritization: Does the solution help teams investigate suspicious or exposed endpoints, or does it only generate an inventory?
Integration with existing workflows: Can findings be incorporated into the team's API governance, security monitoring, and remediation processes?
For a concrete example of this approach, Prophaze's Runtime API Discovery Tool describes a runtime-based method for identifying active API endpoints and investigating shadow, zombie, and undocumented APIs. Its stated capabilities include API inventory, behavioral analysis, and risk prioritization.
As with any security solution, teams should evaluate those capabilities against their own architecture, traffic coverage, and operational requirements.
Discovery is only the starting point
Finding an undocumented API does not automatically fix the underlying risk.
Once an endpoint has been identified, the next step is to establish whether it is required. If it is legitimate, it should be documented, assigned an owner, and protected with appropriate authentication, authorization, validation, and monitoring controls.
If it is obsolete, the team should determine whether it can be safely retired. If it is exposed unexpectedly, access restrictions and remediation may be necessary.
This is where runtime API discovery becomes part of a broader API security process rather than a standalone inventory exercise.
Keeping that inventory current also requires ongoing attention. Applications change, integrations evolve, and new endpoints appear. A discovery process that reflects those changes can help teams avoid relying on outdated assumptions about their attack surface.
Final thoughts
API security depends partly on knowing what needs to be protected.
Documentation, source-code analysis, and gateway configurations all contribute to that understanding. Runtime API discovery adds another perspective by examining the endpoints visible in actual application traffic.
For development and security teams, the useful question is not just whether an API has been documented. It is whether the inventory still reflects what is running, what is accessible, and what needs attention.
That is a practical place to start when improving API visibility.
Top comments (0)