Shadow APIs are endpoints that exist and are reachable but are not in your official inventory: old versions, forgotten test endpoints, or APIs stood up outside change control. Attackers find them by scanning from the outside, and they often lack the authentication and monitoring of documented APIs. Discovery is the only way to close the gap.

Your API inventory probably looks accurate.

That does not mean it is.

Modern applications rarely have one clean set of endpoints managed by one team. APIs are deployed by development teams, acquired through mergers, introduced by contractors, created for mobile applications, duplicated for testing, and sometimes left running long after the project that created them has ended.

Some become shadow APIs.

The problem is not simply that they are undocumented.

The problem is that attackers do not care whether your internal documentation says an endpoint exists.

If it responds to requests from the internet, it is part of your external attack surface.

From an attacker’s perspective, an undocumented API is not invisible. It is simply an endpoint that the organisation may not realise it needs to defend.

What a shadow API is, and how they appear

A shadow API is an internet-reachable API endpoint that is missing from an organisation’s official inventory or outside its normal security and change management processes.

They can appear in several ways.

Old API versions

An application moves from version one to version two.

The development team migrates legitimate users to the new version, but version one remains accessible.

The old endpoint may still connect to the same backend systems and databases.

The newer version may have stronger authentication, validation, or security controls that were never applied to the older version.

From an attacker’s perspective, that makes the older endpoint worth investigating.

Test and staging endpoints

Development teams need environments where they can test new functionality.

The problem begins when those environments become internet accessible and remain online.

A staging endpoint might contain production-like functionality, internal debugging features, or authentication controls that were never intended for public access.

If it is reachable, an attacker can test it.

Unmanaged deployments

Modern development makes it easy to deploy services quickly.

A developer can create an API, connect it to cloud infrastructure, expose it through a domain, and begin testing without necessarily updating the central asset inventory.

The deployment works.

The documentation does not.

Months later, nobody remembers that endpoint exists.

Why shadow APIs are dangerous

Shadow APIs create a visibility problem first.

Security teams cannot validate an endpoint they do not know exists.

That becomes more serious when the endpoint has weaker controls than the production API.

A shadow API may have:

• Missing authentication
• Weak authorisation
• Outdated software
• Debug functionality
• Poor rate limiting
• Weak logging
• Excessive data exposure
• Old API versions
• Direct access to production data

The risk becomes particularly significant when a forgotten endpoint is connected to real information.

An API does not need to look important to expose something valuable.

A test endpoint might connect to the same database as a production application.

An old API version might still accept requests that bypass controls introduced in a newer release.

A forgotten administrative endpoint might expose functionality that was never intended for external users.

The OWASP API Security Top 10 guidance on Improper Inventory Management specifically highlights old API versions, exposed endpoints, outdated documentation, and missing inventories as security concerns.

How attackers discover shadow APIs before you do

Attackers do not need your API documentation.

They can start with what is publicly observable.

External reconnaissance can reveal:

• DNS records
• Subdomains
• API-specific hostnames
• SSL certificates
• Application paths
• Old domains
• Cloud-hosted services
• Documentation portals
• Versioned endpoints

An attacker might discover:

api.example.com

and then investigate whether other versions or environments exist.

They may look for patterns such as:

api.example.com/v1

api.example.com/v2

dev-api.example.com

staging-api.example.com

beta-api.example.com

old-api.example.com

The names themselves are not proof of a vulnerability.

They are clues.

The attacker then validates which endpoints respond, what authentication they require, what functionality they expose, and whether they provide a path to sensitive information.

OWASP notes that attackers can use techniques such as DNS enumeration and other internet-facing discovery methods to find unnecessarily exposed API hosts.

This creates a straightforward problem for defenders.

If the attacker can discover the endpoint from outside, your internal inventory is already behind.

Why documentation and gateways miss them

API documentation is useful.

It is not an authoritative view of the external attack surface.

Documentation describes what teams believe they have deployed.

External discovery shows what is actually reachable.

The difference can be significant.

An API gateway may also provide strong protection for the endpoints routed through it.

But not every API necessarily passes through the same gateway.

A forgotten cloud workload, legacy application, development environment, or independently deployed service may have its own public endpoint.

That creates a security boundary outside the controls the organisation assumes are protecting its APIs.

This is why internal inventories, documentation, and gateway configuration should be treated as sources of information rather than proof of external coverage.

The attacker’s view is different.

If an endpoint responds, it needs to be considered.

Continuous external discovery, then validation

Finding shadow APIs is the first step.

The next question is whether they are exploitable.

Continuous external discovery helps identify changes to the API attack surface as they happen.

New endpoints appear.

Old endpoints disappear.

Domains change.

Cloud services are deployed.

API versions are retired.

The inventory therefore needs to change with the environment.

Once an endpoint is discovered, validation can determine:

• Whether authentication is required
• Whether authentication can be bypassed
• Whether authorisation is correctly enforced
• What data the endpoint exposes
• Whether sensitive functions are accessible
• Whether outdated components are present
• Whether security controls behave as expected

This distinction matters.

A newly discovered API is not automatically a vulnerability.

It becomes a security priority when validation proves that the endpoint creates meaningful exploitable exposure.

Attack Insights’ API security capabilities combine external discovery with validation to help security teams understand which exposed APIs actually require action.

Bringing shadow APIs under control

Once shadow APIs have been discovered and validated, organisations need a process for bringing them into the managed environment.

That does not necessarily mean shutting everything down immediately.

Each endpoint should be assessed according to its purpose and exposure.

Retire what is no longer needed

If an endpoint has no legitimate business purpose, remove it.

An unused API does not provide business value.

Keeping it online only creates another external exposure to manage.

Secure legitimate endpoints

If an API is required, bring it under the same security standards as documented production APIs.

Review:

• Authentication
• Authorisation
• Rate limiting
• Logging
• Encryption
• Input validation
• Data exposure
• Monitoring

Separate non-production environments

Development and staging endpoints should not automatically be treated like production services.

They should have clearly defined access requirements and should not expose production data unnecessarily.

Maintain an external inventory

The inventory should reflect what is actually reachable from the internet, not simply what development teams have documented.

This is where Attack Surface Management becomes valuable.

Continuous external discovery provides an outside-in view that can identify assets and endpoints that internal processes have missed.

The real API inventory is what attackers can reach

A spreadsheet can tell you what your organisation believes it owns.

An external view tells you what an attacker can actually reach.

That distinction is the core problem with shadow APIs.

The endpoint does not become dangerous because someone forgot to document it.

It becomes dangerous because it exists outside the security processes designed to protect it.

Attackers will continue searching for old API versions, forgotten test environments, unmanaged deployments, and endpoints that were never included in the official inventory.

Security teams need to search from the same perspective.

Discover continuously.

Validate what you find.

Prove which endpoints are exploitable.

Then bring them under control.

Request a Demo

You cannot secure an API that you do not know exists.

Request a demo of Attack Insights to see how our API security and Attack Surface Management capabilities continuously discover exposed endpoints, validate exploitable weaknesses, and help bring shadow APIs under control.

FAQ

What is a shadow API?

A shadow API is an internet-reachable API endpoint that is not included in an organisation’s official API inventory or normal security processes. It may be an old API version, forgotten test endpoint, unmanaged deployment, or service created outside established change control.

Why are shadow APIs risky?

Shadow APIs may lack the authentication, authorisation, monitoring, patching, and security controls applied to documented production APIs. They can also expose real data or connect to production systems, creating exploitable paths that security teams may not know they need to validate.

How do attackers find shadow APIs?

Attackers discover shadow APIs by scanning the external attack surface for domains, subdomains, API hosts, versioned paths, cloud services, staging environments, and other internet-facing endpoints. They do not need access to internal documentation to find a reachable API.

How do you find your own shadow APIs?

The most reliable approach is continuous external discovery from the attacker’s perspective. External discovery identifies what is actually reachable, including endpoints missing from internal documentation. Those endpoints can then be validated to confirm whether they create exploitable exposure.