Shadow API detection checklist: How to identify undocumented APIs

Table of Contents

1. Why shadow API detection matters
2. Shadow API detection checklist
3. Step 1: Build a baseline API inventory
4. Step 2: Compare documentation against runtime activity
5. Step 3: Search logs for unknown endpoints
6. Step 4: Inspect code, repositories, and CI/CD pipelines
7. Step 5: Check cloud, Kubernetes, and serverless exposure
8. Step 6: Search DNS and subdomains for API exposure
9. Step 7: Discover APIs from the outside
10. Step 8: Validate exposure and access control
11. Step 9: Classify sensitive data and business functionality
12. Step 10: Establish ownership and classify the API
13. Step 11: Test active APIs for vulnerabilities
14. Step 12: Prioritize and remediate by actual risk
15. Step 13: Bring discovered APIs into continuous governance
16. Step 14: Continuously detect new and changed APIs
17. What to look for in shadow API detection tools
18. How Invicti helps discover and secure shadow APIs
    1. Request for free Invicti Trial

Shadow APIs can emerge wherever deployed systems no longer match approved documentation. This practical checklist describes how undocumented APIs can be identified across source code, runtime traffic, gateways, DNS, infrastructure, and applications. It also covers exposure validation, security testing, ownership assignment, and the steps required to return discovered APIs to proper governance.

Shadow APIs are active API endpoints that sit outside approved documentation, inventories, ownership records, or security testing processes. They often arise through routine development activities. A temporary endpoint may remain in production indefinitely. An earlier API version may stay accessible after replacement. A mobile backend may never be added to the central catalog. A service may also be deployed without passing through the standard API gateway.

Regardless of how such APIs appear, the security issue remains the same. An API that is unknown to the organization is unlikely to receive the same level of security testing, monitoring, and governance as an identified and managed API.

This shadow API detection checklist provides AppSec, API security, platform, and development teams with a practical method for locating undocumented APIs, confirming their exposure, evaluating their security, and bringing them under established controls.

A shadow API is an active API that falls outside an organization’s approved inventory, documentation, ownership model, or security processes. Its existence does not automatically mean that it is vulnerable or malicious. Until the API has been identified and evaluated, however, its security posture remains 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 connections. APIs are continuously created and modified by different teams and across multiple environments. As a result, documented inventories can quickly stop reflecting what is actually deployed.

This mismatch has direct implications for security.

OWASP lists Improper Inventory Management as API9:2023 in the OWASP API Security Top 10 2023. Other API security 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 contain any of these weaknesses. At the same time, it may remain outside routine security testing.

The challenge therefore goes beyond identifying an unfamiliar URL. Shadow API detection must determine what exists, whether it can actually be reached, what functionality it provides, who is responsible for it, what data it processes, and whether the intended security controls function correctly.

Shadow API risk	Why it matters
Unknown exposure	An endpoint that is absent from the inventory may also sit outside established security controls
Authentication gaps	Legacy, temporary, or test endpoints may rely on weaker authentication mechanisms than current services
Authorization weaknesses	Undocumented APIs may not receive the access control testing applied to governed endpoints
Sensitive data exposure	Unknown endpoints can create untracked access paths to customer, financial, health, authentication, or other business data
Missing ownership	Remediation becomes more difficult when no team is accountable for an API
Security testing gaps	APIs outside the testing inventory can remain untested
Lifecycle drift	Deprecated API versions may remain accessible long after their replacements have been introduced
Governance gaps	Untracked APIs make the application attack surface harder to understand and control

A practical way to address this problem is to compare several different representations of the API environment:

• Documentation represents what is expected to exist.
• Source code shows what development teams have implemented.
• Infrastructure reveals what has actually been deployed.
• Runtime observations show what is actively being used.
• External discovery identifies what is genuinely reachable.

Shadow APIs are most likely to surface in the differences between these views.

Shadow API detection checklist

Effective shadow API detection requires comparison of the approved API inventory with several independent sources of evidence. Anything that exists in the deployed environment but not in governance records should then be investigated.

The following checklist can serve as the foundation for a repeatable API discovery process. Each step is explained in greater detail below.

Step	Detection task	Evidence to collect
1	Build the known API inventory	API catalogs, specifications, gateway routes, service registries
2	Compare documentation with runtime observations	Requests or endpoints that do not correspond to known specifications
3	Review gateway and infrastructure logs	Unknown paths, methods, hostnames, versions, and clients
4	Inspect source code and deployment pipelines	Routes, controllers, handlers, API specifications, serverless functions
5	Check cloud and container infrastructure	Gateway routes, functions, ingress rules, services, direct access paths
6	Search DNS and subdomains	API hostnames, stale records, forgotten environments, direct service exposure
7	Discover externally reachable APIs	API hosts, endpoints, application calls, staging systems, old versions
8	Validate exposure and access controls	Authentication, authorization, privileges, rate limits, gateway coverage
9	Classify data and business sensitivity	Sensitive records, credentials, tokens, privileged operations
10	Establish ownership and lifecycle status	Owner, business purpose, environment, active or deprecated status
11	Test active APIs for vulnerabilities	DAST and API security testing results
12	Prioritize and remediate	Exposure, exploitability, privilege, data sensitivity, business impact
13	Add the API to continuous governance	Inventory, monitoring, testing, vulnerability management
14	Repeat discovery and detect inventory changes	Newly observed endpoints, changed APIs, and inventory drift

Step 1: Build a baseline API inventory

Shadow API detection requires a reference point. The process starts with creation of the most complete possible inventory from approved sources.

Relevant sources include OpenAPI or Swagger specifications, GraphQL schemas, API gateway configurations, service registry records, internal API catalogs, and other formal API definitions. Internal, partner, mobile, and machine-to-machine APIs should be included rather than restricting the inventory to publicly exposed endpoints.

The deployment environment also matters. An API that has been removed from production may still be active in staging or QA. Similarly, a development or preview environment originally intended to exist temporarily can eventually become part of the externally accessible attack surface.

A useful API inventory contains more than a hostname and endpoint path:

Inventory field	Why it matters
Hostname	Identifies the location where the API is exposed
Path and HTTP method	Defines the operation provided by the API
Environment	Separates production, staging, test, and development deployments
Authentication	Indicates how access is controlled
Data classification	Helps determine the potential impact of exposure
Owner	Establishes accountability for remediation
Source	Records where the API was documented or discovered
Last observed activity	Helps distinguish active endpoints from dormant ones
Lifecycle status	Identifies active, deprecated, test, or unknown services

A real-time API inventory should function as an active security record rather than a static spreadsheet. Effective API inventory management also requires processes for ownership, lifecycle tracking, change monitoring, and security testing. Otherwise, newly discovered APIs may simply become additional database entries without entering proper security governance.

Step 2: Compare documentation against runtime activity

API specifications describe intended behavior. They do not always reflect the reality of deployed systems.

Known API definitions should therefore be compared with observed runtime activity. Differences can reveal undocumented functionality or older services that remain accessible.

Known inventory	Observed behavior	What it could indicate
/api/v1/users	/api/v1/users/export	Undocumented functionality
GET is documented	POST is also accepted	Undocumented write operation
/api/v2/orders	/api/v1/orders still receives traffic	Legacy or zombie API
No mobile API documented	Mobile client calls /mobile/api/session	Undocumented mobile backend
No gateway route exists	Origin receives API traffic	Direct access or gateway bypass

The length of the observation period is important. An endpoint used by a monthly integration or an occasional partner process may not appear during a brief monitoring window. Conversely, the absence of traffic does not prove that an endpoint is unreachable.

Runtime discovery is therefore highly valuable but incomplete on its own. It reveals what was active during the monitoring period, but it cannot guarantee visibility into every API that could potentially be called.

Step 3: Search logs for unknown endpoints

Existing infrastructure logs can provide valuable discovery evidence even before specialized API discovery technology is introduced.

Possible data sources 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.

Relevant indicators include unknown paths and hostnames, unusual HTTP methods, deprecated API versions, administrative or debug routes, test-related naming patterns, unexpected clients, direct requests to origin infrastructure, and endpoints that return sensitive information.

Correlation is essential. The appearance of /api/internal/export in a proxy log does not automatically mean that the endpoint is a shadow API. The finding needs to be compared against the approved inventory, API specifications, gateway configuration, ownership information, and any other relevant records.

The purpose is to identify unexplained inconsistencies rather than create another uncontextualized list of URLs.

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

Runtime data reveals APIs that are actively being used. Source code can identify APIs before they generate traffic and potentially before deployment to production.

Application repositories can be examined for route definitions, controllers, handlers, serverless functions, GraphQL resolvers, API annotations, and specification files. These definitions can then be compared with the approved API catalog.

Infrastructure as code (IaC) and deployment configurations provide another useful perspective. Gateway definitions, ingress rules, DNS settings, serverless triggers, container services, and continuous integration and continuous delivery (CI/CD) manifests can expose APIs that were never included in central documentation.

Source	Potential clue
Route or controller definition	Endpoint exists in code but is absent from the inventory
API specification	Specification exists but was never registered in the central catalog
Serverless function	HTTP trigger or function URL exposes an unknown service
IaC template	Gateway or ingress route exists outside the API catalog
Deployment manifest	Service is exposed in staging or production
Mobile application	Client references an undocumented backend
Legacy repository	Older API version may still correspond to an active deployed service

Code-based discovery also creates an important shift-left opportunity. An undocumented API can potentially be detected before deployment rather than only after it becomes reachable.

Development processes can also require an API specification or equivalent inventory record before release. Deployment gates may then verify that newly introduced API routes have been registered and approved. Such measures cannot completely eliminate shadow APIs, particularly in large or decentralized environments. They can, however, reduce the number created through normal process drift.

Step 5: Check cloud, Kubernetes, and serverless exposure

Distributed infrastructure increases the number of places where APIs can appear outside the expected production path.

Relevant areas include 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.

One especially important question is whether a service can be reached directly instead of passing through the gateway or another expected security control. An API gateway inventory can provide a highly reliable view of APIs managed by that gateway. By definition, however, it cannot provide complete visibility into services that bypass the gateway.

Cloud and container environments can also change rapidly. Comparisons between deployed infrastructure and the approved API inventory therefore need to be repeatable rather than limited to an annual audit.

Step 6: Search DNS and subdomains for API exposure

DNS provides another perspective on the API attack surface. It can be particularly useful for identifying endpoints and environments that have disappeared from central documentation.

Known domains and subdomains can be reviewed for naming patterns such as api, api-v1, api-v2, mobile, partner, internal, dev, test, staging and legacy. The resulting records can then be compared with approved asset and API inventories.

Stale or unexplained DNS entries deserve particular attention. A hostname created for a migration, proof of concept, previous API release, or temporary environment may continue resolving long after the original initiative has ended.

DNS discovery alone does not demonstrate that an API exists or can be reached. A hostname may resolve to an inactive service. At the same time, an API can exist without any obvious API-related hostname. DNS should therefore be treated as another discovery signal that requires validation through infrastructure, runtime, and application evidence.

The opposite condition also needs consideration. Services may be directly reachable through an IP address, cloud-generated hostname, load balancer address, or serverless URL and therefore avoid the organization’s normal public DNS naming conventions entirely.

Step 7: Discover APIs from the outside

Internal records describe the APIs already known to the organization. External discovery helps establish which parts of the API attack surface can actually be reached from outside the organization.

Relevant targets include externally accessible API-related hosts, development and staging environments, previous API versions, mobile backends, partner-facing services, and APIs exposed through web applications.

Dynamic application security testing (DAST) can provide another discovery signal. During web application crawling, a scanner can observe API requests generated by the application and reveal endpoints that may not be apparent from either documentation or the user interface.

This technique is especially useful for APIs connected to web applications, but it is not a complete discovery method. Headless APIs and service-to-service APIs may not have a web interface available for crawling. Traffic-based analysis has a similar limitation because it only detects APIs that produce observable traffic.

Effective API discovery combines several perspectives rather than treating any single source as complete.

Step 8: Validate exposure and access control

Discovery confirms that an API exists. The next task is to determine its security significance.

For every suspected shadow API, relevant questions include whether the endpoint is internet-facing or internally reachable, whether authentication is required, which identities and roles can access it, what operations are available, and which security controls protect the service.

Authorization deserves particular attention. Authentication establishes the identity of a caller. Authorization determines whether that authenticated caller is permitted to access a specific object or execute a particular function.

For example, broken object-level authorization (BOLA) occurs when an API accepts a valid authenticated request but does not verify whether the caller has permission to access the requested object. Testing for this weakness requires more than confirming the presence of an authentication token. Access boundaries between different users must also be tested.

Undocumented administrative operations or alternative HTTP methods can similarly introduce function-level authorization weaknesses.

The OWASP API Top 10 provides a useful reference for the types of weaknesses that should be considered. At this stage, however, the immediate objective is classification. The endpoint’s exposure and privileges need to be understood well enough to determine the urgency of deeper testing or containment.

Step 9: Classify sensitive data and business functionality

Undocumented APIs can differ significantly in the level of risk they represent.

An internal health-check endpoint that returns non-sensitive status information presents a different risk profile from an internet-facing export endpoint that exposes customer records. Effective prioritization therefore requires both business context and data context.

Relevant analysis includes determining whether the API processes personally identifiable information (PII), payment data, health information, credentials, tokens, intellectual property, or other sensitive business information. Operations capable of creating, modifying, deleting, approving, transferring, exporting, or administering resources should also be identified.

Sensitive business processes require particular attention. OWASP API6:2023, Unrestricted Access to Sensitive Business Flows, recognizes that legitimate API functionality can still create serious security risk when it can be automated or abused without sufficient controls.

Step 10: Establish ownership and classify the API

APIs missing from the inventory do not all fall into the same category:

API type	Description	Primary concern
Shadow API	Active but undocumented, unknown, or unmanaged	Unknown security posture
Zombie API	Deprecated API that remains accessible	Outdated functionality and controls
Rogue API	API deployed outside approved governance	Missing review and accountability
Orphaned API	API without a clearly identified owner	Remediation and lifecycle problems
Internal API	API intended exclusively for internal use	Unexpected external exposure
Partner API	API used for third-party integrations	Access and data governance
Test or staging API	Non-production API that remains reachable	Weaker controls or exposure of test data

These classifications can overlap. A deprecated endpoint that has been forgotten by the original development team may qualify as both a zombie API and a shadow API. A staging API exposed directly to the internet may simultaneously be undocumented, orphaned, and improperly exposed.

Classification only provides value when it results in action. Every active API should have an accountable owner and a clearly understood business purpose.

Failure to identify an owner is itself important security and governance information. An API without an accountable team is less likely to receive timely updates, vulnerability remediation, lifecycle management, or reassessment when its business purpose changes.

Step 11: Test active APIs for vulnerabilities

The discovery of an API does not establish that the API is vulnerable.

Any API that remains active should become part of the organization’s API security testing process. At this point, discovery begins producing concrete security evidence.

Dynamic application security testing is particularly important because many API vulnerabilities depend on runtime behavior. Authentication failures, authorization weaknesses, injection vulnerabilities, security misconfigurations, and workflow-related problems cannot be fully evaluated from inventory information alone.

Authenticated testing is especially important for APIs because valuable functionality commonly exists behind a login, token, or service identity. Testing only unauthenticated endpoints may miss authorization weaknesses and other issues that appear only after a legitimate session has been established.

Where technically feasible, security testing can be automated throughout the software development lifecycle (SDLC), including pre-production environments. This reduces the likelihood that an undocumented and vulnerable API will only be identified after it has already been operating in production.

Step 12: Prioritize and remediate by actual risk

The fact that an API is undocumented should not automatically be treated as a vulnerability severity rating.

Prioritization should take into account factors such as external exposure, authentication and authorization controls, data sensitivity, privilege level, write or administrative capabilities, known vulnerabilities, business criticality, ownership, and whether the endpoint bypasses expected gateway or security mechanisms.

A practical prioritization model can be structured as follows:

Priority	Example criteria	Recommended response
P0	External, unauthenticated, and exposes sensitive data or privileged functionality	Restrict or block immediately and investigate
P1	External, undocumented, sensitive, or demonstrably vulnerable	Assign ownership, perform thorough testing, and remediate controls
P2	Internal but handles sensitive data or privileged functions	Validate identity, authorization, segmentation, and testing
P3	Deprecated or rarely used legacy API	Define a decommissioning plan
P4	Legitimate low-risk API missing from documentation	Add to inventory, assign ownership, and include in routine monitoring

This matrix should not be applied mechanically. A rarely used endpoint with administrative privileges may present substantially more risk than a heavily used read-only API. Confirmed vulnerabilities should also increase remediation priority beyond what would be indicated by exposure alone.

Every API identified during discovery should result in a defined action: document it, secure it, restrict it, deprecate it, or remove it.

A legitimate API that remains necessary should be documented, assigned to an accountable owner, placed behind approved security controls where appropriate, and incorporated into regular monitoring and security testing. Weak authentication or authorization should be remediated just as it would be for any other production service.

Legacy APIs may require gradual deprecation when existing clients still depend on them. APIs that no longer support a legitimate business requirement should be disabled or removed. However, the simple fact that an API is shadow does not mean that deletion is always the correct response.

In some cases, the endpoint itself is legitimate and the underlying governance process is what failed. The appropriate action is then to bring the API into the established governance model rather than remove it.

The resulting decision should be recorded in vulnerability management and API inventory workflows. This prevents the same endpoint from being repeatedly rediscovered and investigated from the beginning.

Step 13: Bring discovered APIs into continuous governance

Identifying and remediating one shadow API resolves a single case. The broader goal is to integrate that API into normal security operations.

This involves updating the API inventory, assigning ownership, recording lifecycle status, including the API in relevant monitoring, defining required controls, and incorporating it into ongoing API security testing.

For APIs undergoing active development, these controls can also be integrated into development workflows. API specifications and inventory records can be validated through CI/CD, while security testing can be performed in pre-production and at other suitable stages of the SDLC.

For organizations operating large API estates, the connection between discovery, inventory, testing, and remediation is particularly important. Without that connection, API discovery risks becoming another source of security data that requires manual reconciliation instead of reducing unknown exposure.

Step 14: Continuously detect new and changed APIs

A one-time inventory only answers a historical question: “Which APIs could be identified at that point in time?”

The more relevant security question is: “Which APIs exist now, and what has changed?”

API environments are constantly changing as organizations roll out new services, update mobile applications, add partner integrations, revise microservices, deploy cloud functions, and maintain legacy API versions during migration periods. An inventory that was accurate three months earlier may therefore already be incomplete.

Continuous controls can reduce this type of drift:

Continuous control	Purpose
Multi-layer API discovery	Identifies APIs through multiple independent signals
Inventory correlation	Detects discrepancies between known and discovered APIs
Change detection and inventory diffing	Highlights newly added, modified, removed, or unexplained APIs
Runtime observation	Identifies APIs that are actively receiving traffic
Source code discovery	Detects APIs during development
CI/CD inventory checks	Flags new API routes that have not entered approved governance
API specification requirements	Creates a defined record for new APIs before or during release
DAST and API scanning	Tests active endpoints for runtime vulnerabilities
Ownership review	Keeps accountability information current
Lifecycle review	Identifies APIs that should be deprecated or removed

The objective is not simply to perform discovery more often. The goal is to create a continuous process that automatically, or with very limited manual intervention, brings newly discovered or changed APIs into inventory management, security testing, ownership assignment, and remediation workflows.

This process also provides a practical way to measure how far the current API inventory has drifted from the actual environment. If every discovery cycle repeatedly identifies APIs that were previously unknown to security teams, the issue extends beyond individual shadow endpoints. This points to shortcomings in development, deployment, or inventory management practices that allow APIs to stay outside established governance.

What to look for in shadow API detection tools

Any evaluation of API discovery capabilities should take into account that no single discovery method can provide complete visibility across the entire API environment:

• Gateway data can be highly authoritative for managed APIs but cannot identify endpoints that bypass the gateway.
• Runtime traffic reveals APIs that are actively used but may miss dormant or infrequently called services.
• Source code analysis can identify endpoints before deployment but cannot prove that those endpoints are reachable.
• Web application scanning can discover APIs exercised by an application but may not reveal headless services.

The most comprehensive approach combines several discovery signals and then connects the results to security testing.

Depending on the environment, these capabilities may be delivered through a single platform or through several integrated tools across AppSec, API management, observability, and asset management processes. Each capability adds a different type of visibility and security context:

Capability	Why it matters
Multi-layer API discovery	Reduces the blind spots associated with relying on a single discovery method
Source code discovery	Identifies APIs before deployment
Runtime traffic discovery	Reveals APIs that are actually being used
API gateway discovery	Adds visibility into centrally managed routes
Application-based discovery	Identifies APIs exercised by web applications
API specification handling	Uses existing definitions and reduces manual configuration
Change detection and inventory diffing	Detects new or modified APIs that diverge from the approved inventory
Authentication support	Provides access to protected functionality for realistic testing
Stateful API testing	Tests workflows that extend across multiple requests
Sensitive data classification	Helps determine the potential impact of API exposure
Ownership mapping	Links discovered APIs to accountable teams
Vulnerability validation	Helps distinguish confirmed security issues from theoretical exposure
Continuous inventory	Keeps information about discovered APIs current
Vulnerability management integration	Connects API findings with ownership and remediation processes

A discovery-focused tool can confirm that an API endpoint is present. For AppSec teams, greater value comes from being able to assess whether that endpoint is actually vulnerable and provide the responsible remediation team with clear, actionable evidence.

How Invicti helps discover and secure shadow APIs

Invicti treats API visibility as a multi-layer discovery challenge.

Rather than relying on a single data source, the platform combines API discovery signals from source code, network activity, API gateways, and web application scanning. Source code analysis can uncover API endpoints and specifications while applications are still being developed. Dynamic scanning can capture API requests generated by live web applications, while gateway and network data add further insight into APIs that are deployed and in active use.

Taken together, these discovery methods help identify gaps between the documented API inventory and the services that are actually present in the environment. This includes shadow, zombie, headless, and service-to-service APIs.

Discovery findings are incorporated into an API inventory that is kept continuously up to date and into ongoing security testing processes. Invicti can also derive or rebuild API schemas from the sources identified during discovery. This allows APIs to be prepared for scanning without depending entirely on manually provided specifications.

Invicti’s DAST foundation becomes particularly relevant at this stage. Once an API has been identified, the same platform can perform dynamic testing to detect vulnerabilities that appear during runtime, including weaknesses specific to API behavior. Stateful and authenticated testing makes it possible to assess complete API workflows and validate access controls instead of limiting the assessment to separate unauthenticated requests.

For vulnerability types covered by proof-based scanning, Invicti can also verify exploitability in a safe manner and include supporting evidence with the reported issue. This makes it easier to differentiate a confirmed security flaw from the mere existence of an undocumented API endpoint.

The resulting process connects the main stages of API security management: API discovery, continuous inventory maintenance, testing of reachable endpoints, validation of real vulnerabilities, prioritization of findings, and integration of remediation into the broader AppSec program.

Request for free Invicti Trial

Leave your contact details and we will get in touch with you

I agree to the privacy policy