How can security teams tell whether shadow APIs are still hiding in production?

What shadow APIs look like once they reach production

Shadow APIs are endpoints that exist outside the approved inventory, often because a team deployed them quickly, a legacy service was forgotten, or a parallel version was left exposed. In production, they usually reveal themselves through live traffic, unexpected response patterns, or endpoints that continue to serve business data even though no system of record acknowledges them.

The practical question is not whether an endpoint technically responds, but whether the organisation can explain why it exists, who owns it, what it exposes, and whether it is covered by the same governance as approved APIs. If those answers are missing, the endpoint is already operating outside control.

How to spot them with runtime evidence, not assumptions

The most reliable test is to compare what is being observed at runtime with what is recorded in the API inventory. Discovery tools, gateway logs, service maps, and telemetry from WAFs or API management platforms should converge on the same endpoint set. When they do not, the gap is the first sign that the inventory is stale or incomplete.

Pay particular attention to traffic that lacks an obvious owner, business service mapping, sensitivity label, or review record. A real production API should usually leave some governance trail, even if that trail is imperfect. If an endpoint is generating requests but no team can explain its purpose or attest to its approval, treat it as a candidate shadow API until proven otherwise.

Volume and persistence matter too. One-off probes may be noise, but repeated discovery of untracked endpoints, versions, or routes means the control plane is not keeping pace with deployment reality. That is especially important when OWASP API Security Top 10 risks are in play, because broken authorisation, unsafe exposure, and unexpected resource access often show up first in ungoverned endpoints.

What the inventory gap is really telling you

A shadow API is rarely just an endpoint hygiene issue. It usually indicates a breakdown in API lifecycle governance, ownership assignment, or change control. If runtime discovery keeps finding more endpoints than the organisation can account for, the approved inventory is no longer a trustworthy source of truth and cannot be used confidently for access review, decommissioning, or exposure assessment.

That gap also creates security blind spots. Untracked APIs are harder to test, harder to monitor, and easier to leave overexposed than deliberately managed services. Teams may assume authentication, authorisation, logging, or throttling are in place when they are not. In practice, the inventory mismatch is often more important than the endpoint itself, because it shows the governance process has already failed once.

For control alignment, the core issue maps to API access governance, change tracking, and secure inventory management. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because access control, audit, configuration management, and monitoring all contribute to keeping the live endpoint set aligned with approved services.

What to do when you find one

First confirm whether the endpoint is truly unauthorised, or simply missing from documentation. Then validate whether it handles sensitive data, supports write actions, or bypasses the normal gateway and policy layer. The higher the data sensitivity and the weaker the surrounding controls, the more urgent the response should be.

If the endpoint is legitimate, add it to the inventory with ownership, classification, review cadence, and decommission criteria. If it is not legitimate, contain exposure quickly, then remove or disable it in a controlled way so you do not break dependent workflows. Either outcome should feed back into the governance process that failed to track it in the first place.

Practitioner Guidance

What to verify: Do not trust a single discovery source. Verify whether the same endpoint appears in runtime traffic, gateway policy, source control, deployment records, and service ownership records before you decide it is merely undocumented.

Common mistake: Teams often treat “not in the catalogue” as “not important.” In practice, the dangerous cases are the endpoints that are live, reachable, and operationally useful, because those are the ones most likely to carry real data or privileged functions.

Decision rule: If an endpoint is live and no owner can produce a review record or sensitivity label, treat it as uncontrolled production surface until the opposite is proven.

Practitioner takeaway: The strongest signal is not the presence of an extra endpoint, but the failure of governance to explain and defend it across discovery, ownership, and review.

Related resources from NHI Mgmt Group

• How can security teams tell whether their remote access model is still too dependent on perimeter trust?
• How can security teams tell whether a SaaS application is still worth keeping?
• How can security teams tell whether phone-based authentication is still working?
• How can security teams tell whether Linux privilege boundaries are still effective?