Shadow API detection checklist: How to find undocumented APIs

Shadow APIs are active API endpoints that exist outside approved documentation, inventory, ownership, or security testing processes. They can emerge from ordinary development work – a temporary endpoint that becomes permanent, an old API version that remains accessible, a mobile backend that never enters the central catalog, or a service deployed outside the standard API gateway.

Whatever their origin, the security problem is the same: an API that nobody knows about is unlikely to receive the same testing, monitoring, and governance as a known API.

This shadow API detection checklist gives application security (AppSec), API security, platform, and development teams a practical process for finding undocumented APIs, validating their exposure, assessing their security, and bringing them back under control.

A shadow API is an active API that exists outside the organization’s approved inventory, documentation, ownership, or security processes. A shadow API is not necessarily vulnerable or malicious – but until it is identified and assessed, its security posture is unknown.

Why shadow API detection matters

Modern applications can expose APIs through web and mobile applications, microservices, serverless functions, partner integrations, internal services, cloud infrastructure, and machine-to-machine communication. With APIs being created and changed across different teams and environments, the documented inventory can quickly diverge from what is actually deployed.

That discrepancy has direct security consequences.

OWASP includes Improper Inventory Management as API9:2023 in the OWASP API Security Top 10 2023. Other API risks include broken object-level authorization (BOLA), broken authentication, broken function-level authorization, unrestricted access to sensitive business flows, and security misconfiguration. An undocumented endpoint can potentially contain any of these weaknesses – while also being absent from routine security testing.

The challenge is therefore bigger than finding an unfamiliar URL. Shadow API detection needs to establish what exists, whether it is actually reachable, what it does, who owns it, what data it handles, and whether its security controls work as intended.

The practical answer to this challenge is to compare multiple views of your API environment:

• Documentation tells you what should exist.
• Code tells you what developers have built.
• Infrastructure tells you what has been deployed.
• Runtime observations tell you what is being used.
• External discovery tells you what can actually be reached.

The discrepancies between those views are where shadow APIs tend to appear.

Shadow API detection checklist

To detect shadow APIs, compare your approved API inventory against multiple independent sources of evidence, then investigate anything that exists in reality but not in governance. 

Use this checklist as the starting point for a repeatable API discovery process. See the discussion that follows for details of each step.

Step 1: Build a baseline API inventory

Shadow API detection needs something to compare against. Start by establishing the most complete inventory you can from approved sources.

Collect OpenAPI or Swagger specifications, GraphQL schemas, API gateway configurations, service registry records, internal API catalogs, and other sources of API definitions. Include internal, partner, mobile, and machine-to-machine APIs rather than limiting the exercise to public endpoints.

Environment matters too. An API removed from production might still be running in staging or QA. Likewise, a development or preview environment that was intended to be temporary can become part of the externally accessible attack surface.

A useful API inventory records more than a hostname and path:

A real-time API inventory should be treated as a working security record rather than a static spreadsheet. Effective API inventory management also needs processes for ownership, lifecycle status, change tracking, and security testing so that newly identified APIs do not simply become additional entries in a database.

Step 2: Compare documentation against runtime activity

Specifications describe intended API behavior. They do not necessarily describe deployed reality. Compare known API definitions with observed activity and look for discrepancies such as:

Observation periods matter. An endpoint used by a monthly integration or occasional partner workflow may not appear during a short monitoring window. Likewise, an endpoint with no observed traffic is not necessarily unreachable.

This is why runtime discovery is powerful but insufficient on its own. It can tell you what was active while you were observing, but not necessarily everything that could be called.

Step 3: Search logs for unknown endpoints

Existing infrastructure logs can provide useful evidence even before dedicated API discovery tooling is deployed.

Relevant sources can include API gateways, reverse proxies, web application firewalls (WAFs), load balancers, content delivery networks (CDNs), Kubernetes ingress controllers, service meshes, application access logs, cloud services, and serverless platforms.

Look for unknown paths and hostnames, unusual HTTP methods, deprecated API versions, admin or debug routes, test naming conventions, unexpected clients, direct calls to origin infrastructure, and endpoints returning sensitive information.

The important part is correlation. Finding /api/internal/export in a proxy log does not automatically make it a shadow API. Compare it with the approved inventory, API specifications, gateway configuration, ownership records, and other available sources.

The objective is to identify unexplained discrepancies, not to generate another list of URLs.

Step 4: Inspect code, repositories, and CI/CD pipelines

Runtime evidence shows APIs that are being used. Source code can reveal APIs before they receive traffic – and potentially before they reach production.

Search application repositories for route definitions, controllers, handlers, serverless functions, GraphQL resolvers, API annotations, and specification files. Compare those definitions with the approved API catalog.

Infrastructure as code (IaC) and deployment configuration can provide another view. Gateway definitions, ingress rules, DNS configuration, serverless triggers, container services, and continuous integration and continuous delivery (CI/CD) manifests can all reveal API exposure that never made it into central documentation.

Code-based discovery also provides an important shift-left advantage: an undocumented API can potentially be identified before deployment instead of only after it becomes reachable.

Where the development process supports it, teams can also require an API specification or equivalent inventory record before a new API is released. Deployment gates can then check whether newly introduced API routes have been registered and approved. These controls will not eliminate shadow APIs, especially in complex or decentralized environments, but they can reduce the number created through routine process drift.

Step 5: Check cloud, Kubernetes, and serverless exposure

Distributed infrastructure creates more places for APIs to appear outside the expected route to production.

Check cloud API gateway configurations, serverless HTTP triggers and function URLs, Kubernetes ingress and service definitions, service mesh routing, load balancers, containerized services, preview environments, and staging infrastructure.

A particularly important question is whether a service can be accessed directly rather than through the gateway or other expected security control. Gateway inventory can provide a highly reliable view of APIs managed by that gateway, but by definition it cannot provide complete visibility into services that bypass it.

Cloud and container environments also change quickly. Comparing deployed infrastructure against the approved API inventory should therefore be repeatable rather than reserved for an annual audit.

Step 6: Search DNS and subdomains for API exposure

DNS provides another view of the API attack surface, particularly for endpoints and environments that may no longer appear in central documentation.

Review known domains and subdomains for naming patterns such as api, api-v1, api-v2, mobile, partner, internal, dev, test, staging, and legacy. Compare those records with your approved asset and API inventories.

Pay particular attention to stale or unexplained DNS records. A hostname created for a migration, proof of concept, previous API version, or temporary environment can remain resolvable long after the original project has ended.

DNS discovery alone does not prove that an API exists or that it is reachable. A hostname can point to an inactive service, and an API can exist without an obvious API-related hostname. Treat DNS as another discovery signal to validate against infrastructure, runtime, and application evidence.

The inverse is also worth checking: services that are directly reachable through an IP address, cloud-generated hostname, load balancer, or serverless URL may bypass the organization’s expected public DNS naming conventions altogether.

Step 7: Discover APIs from the outside

Internal records tell you what your organization knows about. External discovery helps establish which parts of your API attack surface are reachable from outside the organization.

Review externally reachable API-related hosts, development or staging systems, old API versions, mobile backends, partner-facing endpoints, and APIs exposed through web applications.

Dynamic application security testing (DAST) can contribute another discovery signal here. When a scanner crawls a web application, it can observe API calls made by the application and identify endpoints that may not be obvious from documentation or the user interface.

This is especially useful for application-connected APIs, but it is not a complete discovery method by itself. Headless APIs and service-to-service APIs may have no web interface to crawl. Conversely, traffic analysis only finds APIs that generate observable traffic.

Effective API discovery combines these perspectives instead of assuming any one of them is complete.

Step 8: Validate exposure and access control

Discovery establishes that an API exists. The next question is what security significance it has.

For each suspected shadow API, establish whether it is internet-facing or internally reachable, whether authentication is required, which identities and roles can use it, what operations it exposes, and which security controls sit in front of it.

Pay particular attention to authorization. Authentication answers who the caller is. Authorization determines whether that caller should be allowed to access a particular object or function.

For example, broken object-level authorization (BOLA) occurs when an API accepts a valid authenticated request but fails to verify that the caller is allowed to access the requested object. Testing for this type of issue requires more than checking whether an authentication token exists – it requires testing access boundaries between users.

Similarly, undocumented administrative operations or alternative HTTP methods can expose function-level authorization problems.

The OWASP API Top 10 provides a useful baseline for the types of weaknesses to consider, but the immediate objective at this stage is classification: understand the endpoint’s exposure and privileges well enough to decide how urgently it needs deeper testing or containment.

Step 9: Classify sensitive data and business functionality

Two undocumented APIs can present very different levels of risk.

An internal health-check endpoint returning non-sensitive status information is not equivalent to an internet-facing export endpoint that returns customer records. Prioritization therefore needs business and data context.

Determine whether the API processes personally identifiable information (PII), payment data, health information, credentials, tokens, intellectual property, or other sensitive business data. Also identify operations that can create, modify, delete, approve, transfer, export, or administer resources.

Sensitive business flows deserve particular attention. OWASP API6:2023, Unrestricted Access to Sensitive Business Flows, recognizes that technically valid API functionality can still create serious risk when automated or abused without appropriate controls.

Step 10: Establish ownership and classify the API

Not every API that is missing from an inventory belongs in the same category:

These categories can overlap. A deprecated endpoint forgotten by its original team can be both zombie and shadow. A staging API exposed directly to the internet can simultaneously be undocumented, orphaned, and incorrectly exposed.

Classification is useful only when it leads to action. Every active API should have an accountable owner and an understood business purpose.

If no owner can be identified, that is itself useful security and governance information. An API with no accountable team is less likely to receive timely updates, vulnerability remediation, lifecycle management, or review when its business purpose changes.

Step 11: Test active APIs for vulnerabilities

Finding an API does not tell you whether it is vulnerable.

Any API that remains active should enter the organization’s API security testing process. This is where discovery turns into security evidence.

Dynamic application security testing is especially important because many API vulnerabilities depend on runtime behavior. Authentication failures, authorization weaknesses, injection vulnerabilities, security misconfigurations, and workflow issues cannot be fully assessed from inventory data alone.

Authenticated testing is particularly important for APIs because valuable functionality commonly sits behind a login, token, or service identity. Testing only unauthenticated endpoints can miss authorization failures and other weaknesses that appear only after a valid session is established.

Where possible, automate testing as part of the software development lifecycle (SDLC), including pre-production environments. That reduces the chance of discovering an undocumented and vulnerable API only after it has been running in production.

Step 12: Prioritize and remediate by actual risk

“Undocumented” should not itself be treated as a vulnerability severity.

Prioritize each discovered API using factors such as external exposure, authentication and authorization, data sensitivity, privilege, write or administrative capabilities, known vulnerabilities, business criticality, ownership, and whether the endpoint bypasses expected gateway or security controls.

A practical prioritization model might look like this:

Avoid using this matrix mechanically. A low-traffic endpoint with administrative access can be far more significant than a heavily used read-only API. Verified vulnerabilities should likewise raise remediation priority beyond what exposure alone would suggest.

Every discovered API should lead to a clear next action: document it, secure it, restrict access, deprecate it, or remove it. 

A legitimate API that is still required should be documented, assigned an owner, routed through approved security controls where appropriate, and added to routine testing and monitoring. Weak authentication or authorization needs remediation just as it would for any other production service.

Legacy APIs may require a staged deprecation process if clients still depend on them. Remove or disable APIs that no longer serve a legitimate business purpose, but do not assume every shadow API should simply be deleted.

Sometimes the endpoint is legitimate and the process is what failed. In that case, the fix is to bring the API into governance rather than remove it.

Record the decision in your vulnerability management and API inventory workflows so that the same endpoint does not have to be rediscovered and investigated from scratch.

Step 13: Bring discovered APIs into continuous governance

Finding and fixing one shadow API solves one instance of the problem. The longer-term objective is to make the API part of normal security operations.

That means updating the API inventory, assigning ownership, recording its lifecycle status, adding it to appropriate monitoring, establishing required security controls, and including it in ongoing API security testing.

Where APIs are under active development, integrate those controls with development workflows. API specifications and inventory records can be checked as part of CI/CD, while security testing can run in pre-production and at other appropriate stages of the SDLC.

For organizations with large API estates, this connection between discovery, inventory, testing, and remediation is critical. Otherwise, discovery can become another source of security data that requires manual reconciliation rather than reducing unknown exposure.

Step 14: Continuously detect new and changed APIs

A one-time inventory answers yesterday’s question: “What APIs could we find?”

The practical security question is different: “What APIs exist now, and what has changed?”

APIs change whenever teams deploy new services, update mobile applications, add partner integrations, modify microservices, create cloud functions, or keep old versions running during migrations. An inventory that was accurate three months ago can therefore be incomplete today.

Continuous controls can help reduce that drift:

The goal is not merely to run discovery more frequently. It is to create a feedback loop in which newly discovered or changed APIs enter inventory, testing, ownership, and remediation workflows automatically or with minimal manual intervention.

That feedback loop also provides a practical measure of inventory drift. If every discovery cycle repeatedly identifies APIs that were unknown to security teams, the problem is not only individual shadow endpoints – it is a gap in the development, deployment, or inventory process that allows them to remain unmanaged.

What to look for in shadow API detection tools

Any evaluation of API discovery capabilities needs to acknowledge that no single discovery signal provides complete API visibility:

• Gateway data can be authoritative for managed APIs but cannot see endpoints that bypass the gateway. 
• Runtime traffic reveals active APIs but can miss dormant or low-frequency services. 
• Code analysis can identify endpoints before deployment but does not prove that they are reachable. 
• Web application scanning can uncover APIs exercised by an application but will not necessarily see headless services.

The strongest approach combines multiple signals and then connects discovery to security testing.

Depending on your environment, these capabilities may come from one platform or from several tools integrated into your AppSec, API management, observability, and asset management workflows. Here’s how each capability layer adds visibility and intelligence:

A discovery-only tool can tell you that an endpoint exists. For AppSec teams, the more valuable outcome is being able to take the next step: determine whether that API is vulnerable and get actionable evidence to the team that can fix it.

How Invicti helps discover and secure shadow APIs

Invicti approaches API visibility as a multi-layer discovery problem.

Rather than relying on a single source, the platform correlates API discovery across source code, network traffic, API gateways, and web application scanning. Source code discovery can identify endpoints and specifications during development, while dynamic application scanning observes API calls exercised by running web applications. Gateway and network signals add additional views of deployed and active APIs.

Together, these discovery methods help expose gaps between what is documented and what actually exists, including shadow, zombie, headless, and service-to-service APIs. 

Discovery feeds a continuously updated API inventory and security testing workflows. Invicti can extract or reconstruct API schemas from discovery sources so APIs can be prepared for scanning without relying exclusively on manually supplied specifications.

This is where Invicti’s DAST foundation becomes especially relevant. Once an API has been discovered, the same platform can dynamically test it for runtime vulnerabilities, including API-specific security issues. Stateful and authenticated testing can exercise API workflows and access controls rather than limiting testing to isolated unauthenticated requests.

For vulnerability classes supported by proof-based scanning, Invicti can also safely confirm exploitability and provide evidence with the finding. This helps teams separate a confirmed security weakness from the simple fact that an undocumented endpoint exists.

The result is a connected workflow: discover APIs, maintain inventory, test what is reachable, validate real vulnerabilities, prioritize findings, and feed remediation back into the wider AppSec program.

Next steps

• For a deeper look at the API attack surface and why unmanaged endpoints appear, read The shadow API crisis: Why API visibility breaks down at scale.
• To compare the strengths and blind spots of gateway, traffic, code, runtime, and DAST-based discovery, see API discovery methods compared.
• When you are ready to evaluate the technology, explore Invicti API Security to see how multi-layer API discovery, continuously updated inventory, and dynamic API security testing work together.
• Ready to see it against your own application and API environment? Request an Invicti demo.