It’s not about how application programming interfaces (APIs) work. It’s not even about API security. It’s about what shadow or orphaned APIs are live right now — and how your teams can tell. As API use has grown substantially over the past few years, it’s become too easy to lose sight of how many APIs are active and how they are being used. Since teams can easily create new API connections or leave unused ones exposed, the actual number of APIs may be far higher than expected, and many of those pose real risks.

So let’s talk about getting every single API on the radar.

A key component of both application security and system architecture hardening, API discovery is the process of identifying and documenting all API connections within a network. This article covers best practices for API discovery, what security teams can expect to find, and the pitfalls to look out for while conducting this process. 

Why API Discovery Matters

APIs are the connective tissue of modern software. They handle communication between countless services across the hybrid and multi-cloud. Today, everything has an API.

Research findings estimate that API calls make up anywhere from 70% to 85% of modern internet traffic.

Though public APIs get the lion’s share of attention, companies use 6 to 7 times the number of internal APIs compared to public ones, and they’re often undocumented and unmanaged. 

Given their tremendous influence on traffic, APIs present a significant security risk to an organization’s system architecture. And traditional security tools were never built to track them dynamically. 

 But API blindspots matter. They:

• Expand the attack surface, often silently. Shadow APIs that are built, but not registered, and forgotten zombie APIs often have weaker controls. 
• Bypass security controls. APIs might not be rate-limited, logged, or authenticated.
• Expose sensitive data unknowingly: APIs can return sensitive customer data.
• Undermine incident response: APIs that no one knows about can’t be included in threat detection, forensics, or takedown procedures. That delays triage and containment.
• Weaken compliance and audit-readiness: Regulations like PCI-DSS, HIPAA, and GDPR require knowing where data flows.

API management only works when teams know what APIs exist. Otherwise, any number of APIs could be left vulnerable, and without monitoring and tools like API gateways, rate limiting, and auth policies, they can’t reach shadow, zombie, and undocumented APIs. 

The Development of API Visibility

Given the ubiquity of APIs and the security risks they present, knowledge about the number and scope of these connections is a vital part of securing an organization’s digital architecture.

APIs present a number of security risks to an organization. By their nature, APIs create openings into internal systems — security holes that serve a purpose but also carry risk. As the number of APIs grows, so does the surface area exposed to potential abuse.

And historically, API visibility relied on:

• Manual approaches, which drift quickly
• API gateways, which only see registered traffic
• Code scanning tools, which miss runtime behavior
• Log analysis, which lacks full context and granularity

As a result, most organizations had old, unmonitored APIs, those created outside governance, and partner or 3rd-party APIs with poor visibility. They also lacked visibility into ephemeral or autoscaled APIs from containers and serverless functions.

With some Cloud-Native Application Protection Platforms (CNAPPs) of today, organizations may still lack visibility. When? 

• Their CNAPP isn’t integrated for runtime insights, and operates via Cloud Security Posture Management (CSPM) or Infrastructure as Code (IaC) scanning only
• They use only API gateways or Web Application Firewalls (WAFs) for visibility
• They’re covering only part of their environment, for example, just production or just cloud, but not on-premises environments
• They rely on agent-based Endpoint Detection and Response (EDR) or Security Information and Event Management (SIEM) logs for API insights that don’t track Layer 7 traffic natively. Layer 7 includes the requests made in communications, not just that a connection occurred. Look for tools that monitor Layer 3 (Who is talking), Layer 4 (Which services and protocols are used), and Layer 7, like API calls.

Today, runtime CNAPPs with eBPF sensors to inspect live traffic do much of the work of API discovery, with one caveat: teams won’t see every potential API route in the codebase, just those actually used in production. That’s a minor issue, since APIs in production are what matter for risk.

Complete visibility also allows teams to shift their view from endpoint-level API discovery to behaviors at the network level, for a deeper understanding of how APIs are being used in their environment. They’ll be able to break down which internal services are generating the most traffic, for example, and whether it’s in-cluster or exposed via internet ingress.

Risks Without Full API Visibility

Many organizations assume their inventory of APIs is accurate, but without continuous runtime discovery, they’re often left in the dark. And in a production environment where APIs are spun up dynamically and evolve with every deploy, those gaps aren’t rare. In fact, they’re constant. When APIs are invisible, they introduce the invisible risk of an API attack. Some of the more common security risks presented by APIs include: 

• Broken Object Level Authorization: This occurs when APIs fail to properly validate and enforce access control restrictions at the object level, allowing attackers to access or manipulate data they shouldn’t. 
• Broken Authentication: Weak or improperly implemented authentication mechanisms — such as missing tokens, predictable credentials, or insecure session handling — can allow attackers to impersonate users or access protected resources. These flaws can lead to data breaches, privilege escalation, or full account takeover.
• Excessive Data Exposure: APIs returning more data than necessary, like entire database objects instead of just required fields, can unintentionally expose sensitive information like user credentials, internal IDs, or configuration details. If proper filtering isn’t enforced server-side, attackers may access data they were never meant to see.
• Lack of Rate Limiting: A lack of rate limiting allows attackers to flood an API with excessive requests, overwhelming system resources and potentially causing service outages. Without these controls, APIs become easy targets for Denial-of-Service (DoS) attacks that degrade performance or make the application unavailable to legitimate users.
• Injection: Vulnerable APIs can be exploited through injection attacks, where attackers supply malicious input, like SQL, command-line, or script code, within API requests. If the API fails to properly sanitize inputs, this can lead to unauthorized data access, execution of unintended commands, or full system compromise.
• Improper Asset Management: Failing to properly maintain and monitor API endpoints, like outdated versions, can expose unmonitored or insecure endpoints to attackers. These improperly managed APIs create the risk of a potential security issue. 
• Insufficient Logging & Monitoring: Without adequate logging and real-time monitoring, malicious activity such as brute-force attempts or data exfiltration can go undetected.
• Insecure Direct Object References (IDOR): This occurs when APIs expose internal object identifiers, for instance, user IDs or file paths, without enforcing access control checks. Attackers can manipulate these references to gain unauthorized access to other users’ data or system resources.
• Unrestricted Resource Consumption: APIs lacking safeguards such as rate limits or quotas can be exploited by attackers to consume excessive CPU, memory, or bandwidth, thus overloading the system. 
• Unrestricted Access to Sensitive Business Flows: Exposing sensitive business workflows without adequate access controls can let attackers automate API abuse and eventually disrupt business operations.
• Mass Assignment: Mass assignment vulnerabilities occur when an API automatically binds user-supplied input to application objects without filtering sensitive fields. Attackers can exploit this to modify protected properties like user roles or permissions.
• Server-Side Request Forgery (SSRF): With SSRF, a vulnerable API can be manipulated into sending requests to internal or otherwise restricted resources, potentially revealing internal infrastructure, sensitive information, or enabling a pivot to further attacks. 
• Security Misconfiguration: APIs with insecure default settings, unnecessary HTTP methods, unpatched components, or exposed error messages can give attackers critical information or open up exploitable flaws. These issues often result from poor deployment hygiene.
• Unsafe Consumption of APIs: Consuming third-party or internal APIs without proper validation, authentication, or schema enforcement can introduce injection risks, trust violations, or logic flaws. This is especially dangerous when chaining APIs together in microservices.

Compliance Challenges

And all these risks combine to make for compliance challenges. Especially for APIs that connect data to systems used throughout the enterprise, it is critical that deployments are secure.

It’s incumbent on security teams to ensure compliance in all API connections, and API discovery is essential for identifying all APIs within an organization. By gaining full visibility, security and compliance teams can ensure that data flows align with privacy regulations such as GDPR, CPRA, or HIPAA. Discovery also helps enforce internal policies by monitoring access, data exposure, and usage patterns across all APIs.

Moreover, organizations must also follow specific deployment guidelines set by API protocol providers. For example, OpenAPI requires standardized schema definitions to ensure compatibility and security across services.

How API Discovery Works

Of course, in a perfect world, teams wouldn’t have to worry about how API discovery works. Tools would handle it automatically at runtime, surfacing every active API without relying on gateways or guesswork.

But for teams still stitching together discovery manually, or evaluating whether their current tools are enough, it’s worth understanding the methods behind API inventory building, and why some approaches fall short.

Manual vs. Automated Methods

In general, API discovery can be conducted manually or via automation. 

Getting Started with Automated Tools in API Discovery

For teams not using a runtime CNAPP tool that fulfills their API discovery needs, they may find they are piecing together visibility using multiple tools, each solving part of the problem, but none providing full, live coverage. Here’s how the traditional stack breaks down:

Automated Discovery Tools

• Automated Scanners: These tools continuously monitor network traffic and applications to identify APIs, both public and private, ensuring all endpoints are accounted for. They work best in static environments but can miss ephemeral endpoints. An example is the open-source ZAP by OWASP for API fuzzing/discovery.
• API Catalogs: These act as organized repositories that maintain up-to-date information about APIs, including their purpose, version, and security requirements. They’re useful for governance, but only as useful as the data fed into them. Consider open-source options with partial functionality, like the core version of SwaggerHub.
• API Security Platforms: These tools focus on both discovery and security assessment, identifying vulnerabilities in APIs and providing solutions to address them. They’re often not integrated at the runtime level, so visibility is incomplete. Look to Zap for basic functionality.

Effective API Discovery Best Practices

Even with a runtime CNAPP providing continuous visibility into live API activity, organizations still need structured processes to operationalize that visibility. Discovery is the start of the process, but it feeds a system that also includes governance, monitoring, and automation, and that reduces risk and improves response time.

Centralized, Runtime-Driven Inventory

A non-negotiable step toward security, compliance, and resilience is establishing a centralized API inventory. This comprehensive catalog should house critical information about all APIs in the organization, both internal and external, including:

• API Name and Description: A clear label and summary of its purpose or function.
• Owner or Responsible Team: Who maintains and supports the API.
• Endpoint URLs: The specific paths where the API can be accessed.
• Authentication Requirements: What kind of auth is enforced (e.g., API key, OAuth, JWT).
• Data Types Exchanged: The kinds of data the API handles, especially sensitive or regulated data.
• Internal vs. External: Whether the API is exposed to the public, third parties, or only used internally.
• Version Information: Active versions and their release or deprecation status.
• Traffic/Usage Metrics: How often it’s used and by whom.
• Security Posture: Known vulnerabilities, encryption protocols, rate limiting, and logging status.
• Compliance Mapping: Which regulations or policies apply to this API (e.g., PCI DSS, HIPAA).
• Environment: Whether the API is running in dev, test, staging, or production.
• Change History: Logs of major updates or ownership changes.

The inventory isn’t built once; it’s continuously updated to reflect only live APIs in production.

Continuous Monitoring at Runtime

Once teams have created the inventory, the next critical step is continuous monitoring. APIs are dynamic; they change, evolve, and can become vulnerable over time. Continuous monitoring ensures organizations stay ahead of potential threats and maintain a secure API ecosystem.

Key practices include:

• Monitoring traffic volume shifts (e.g., a spike to POST /transfer at midnight)
• Tracking access by identity, especially unknown sources or geographic anomalies
• Alerting on unauthenticated or misrouted API calls
• Flagging error codes or latency spikes indicative of abuse, dependency failure, or DDoS
• Maintaining audit trails of API usage by team, service, and account

This is where runtime platforms help: rather than relying on logs of gateway metadata, they observe actual traffic at layer 7, delivering alerts as threats emerge.

Automation Strategies for Resilience

Augment runtime monitoring with automation across the API lifecycle, especially when it comes to security controls, documentation, and testing.

Best practices include: 

• Auto-generating documentation from observed behavior and tagging unknown endpoints for review.
• Integrating discovery into CI/CD pipelines, flagging unregistered APIs before deployment.
• Enforcing policies on exposure, auth, and rate limits via automated rule engines.
• Continuous security testing of exposed APIs based on live request/response pairs, like fuzzing or logic abuse testing.
• Automated alerting for data anomalies, excessive error rates, or abuse patterns.

Beyond finding APIs, automation tools help teams automatically respond to risk and verify their posture with less manual effort.

Upwind Tracks APIs at Runtime

Upwind helps teams discover APIs, but it also shows them how those APIs behave in real-world conditions. By analyzing runtime traffic at Layers 3, 4, and 7, Upwind continuously surfaces active APIs, classifies their sensitivity, and maps data flows, including regulated data like PCI, PII, and PHI. This visibility is generated passively by Upwind’s in-cluster sensors, which inspect traffic without exporting payload data, so teams get better security and deeper analysis.

Want to stop relying on scanning, logs, or declared schemas? See what’s running in production and what’s putting your organization at risk. Schedule a demo to see how you can get streamlined API discovery, even when APIs aren’t declared.

FAQ

How can I discover all my APIs?

Embarking on API discovery requires a structured approach. Here’s a step-by-step guide to get you started:

1. Define Your Goals: Teams need to clearly identify what they hope to achieve with API discovery, such as focusing on security, compliance, or efficiency in development. They must also establish measurable objectives to track progress and success.
2. Inventory Existing APIs: Prior to implementing a tool, organizations should conduct a preliminary inventory of their known APIs. This helps with identifying potential gaps and silos and to gain an overview of the scope of their API landscape. 
3. Choose the Right Tool: Teams should evaluate available tools based on their specific needs. Factors to consider could be features, scalability, and integration capabilities. Ultimately, teams should test their top candidates based on specific organizational needs. 
4. Configure and Integrate: Configure the chosen tool, whether open source or enterprise, to scan the network and discover APIs. These tools should be integrated with existing systems, such as API gateways and CI/CD pipelines, for seamless data flow.
5. Automate Discovery and Documentation: Teams should leverage the tool’s automation features to discover new APIs and update API documentation continuously. This ensures that the inventory remains up to date. 
6. Establish Governance Policies: Always define and implement governance policies for API usage, security, and compliance. The discovery tool can be used to enforce these policies and monitor adherence.
7. Monitor and Analyze: Lastly, teams should continuously monitor API usage, performance, and security. In addition, organizations should analyze the data to identify trends, potential issues, and areas for improvement.

What does the future hold for API discovery?

The field of API discovery is constantly evolving, driven by technological advancements and changing business needs. A few future trends to watch include: 

• AI and machine learning will come to play a more significant role in automating discovery, behavior analysis, and predicting issues. 
• The development of API meshes, requiring tools to evolve to manage and visualize complex inter-API dependencies.
• Enhanced security scanning incorporated into discovery tools, including threat detection and vulnerability assessment.
• Real-time monitoring that can provide deep insights into API performance and usage, enabling proactive issue resolution.

• The rise of Web3 is driving demand for API discovery tools that support decentralized environments.
• An increased focus on API governance in the face of greater data privacy regulations worldwide. 

How do you manage shadow APIs?

Shadow APIs can’t be managed until they’re discovered, so the first step is continuous runtime visibility that reveals every active endpoint, not just those registered in gateways or documentation. 

Once surfaced, security teams can classify, assess, and govern these APIs, just like any other production asset.

• Use runtime traffic analysis, like eBPF sensors, to detect undocumented APIs in real time
• Tag shadow APIs by sensitivity, exposure (internal vs. internet-facing), and auth status
• Assign ownership based on deployment metadata or service identity
• Enforce security policies, for example, auth required or rate limits
• Monitor behavior over time to determine usage, risk, and remediation priority

What are the key implementation challenges?

The biggest challenges in implementing API discovery and security revolve around how to integrate with dynamic environments and maintain continuous visibility without disrupting performance. Teams also struggle with ownership, tool sprawl, and inconsistent enforcement across environments. The challenges to solve include:

• Gaining visibility into ephemeral or containerized APIs not routed through gateways
• Avoiding performance overhead from traditional agents or excessive logging
• Mapping APIs to the correct teams for ownership and remediation
• Normalizing discovery data across multi-cloud and hybrid environments
• Aligning runtime discovery with CI/CD workflows and governance policies

How does API discovery integrate with API security?

API discovery integrates with API security because it enables comprehensive visibility into the organization’s API landscape — the first step to securing it. Knowing what’s in the environment informs security practices like vulnerability mitigation, risk reduction, and overall improvement in proactive security.