An API can be properly secured on paper while an older version, a staging environment or a temporary endpoint is still reachable from the Internet. These unmanaged interfaces are commonly referred to as shadow APIs.
A forgotten API is still an exposed API
Modern applications can accumulate many interfaces: production APIs, old versions, mobile endpoints, test services, administration interfaces and temporary integrations. The problem starts when one of them keeps responding after it is no longer actively tracked.
OWASP lists improper inventory management among the main API security risks. Incomplete or outdated documentation can leave older versions online with weaker security requirements than the current interface.
The gap that matters
The key question is not only “which APIs have we documented?” but also “which services are actually responding from the Internet today?”
Why old interfaces are sensitive
An old API is not automatically vulnerable. It may, however, have missed later improvements such as stronger authentication, request rate limiting, stricter CORS rules, better logging, dependency updates or the removal of deprecated endpoints.
The risk comes from the gap between what the team believes it exposes and what is truly reachable.
Staging is not necessarily private
A test environment may look harmless, yet it can use production-like data, share backend services or keep weaker authentication. A hostname such as staging.example.com or api-v1.example.com can remain online long after a project ends.
OWASP recommends inventorying API hosts, versions and environments — production, test, development or staging — and identifying which ones should actually be accessible.
The problem goes beyond APIs
The same principle applies to the full external attack surface: abandoned subdomains, old applications, administration interfaces, dashboards, development servers and forgotten network services.
Individually, each asset may seem harmless. Together, they form an attack surface that can change faster than internal documentation.
Build an inventory that is actually useful
For every exposed API or service, you should be able to answer a few basic questions:
- What is it used for?
- Is it still needed?
- Should it be reachable from the Internet?
- Which version is running?
- Who owns it?
- When should it be retired or replaced?
For APIs, documenting authentication, errors, redirects, rate limits, CORS rules and available endpoints also reduces the chance of losing track of an interface.
Removing a service can be better than fixing it
When an old service is discovered, the first question should not always be “how do we secure it?” but “do we still need it?”. An unused endpoint adds risk without adding value. In that case, removing it is often the best security control.
Monitor what appears as well
An inventory is not a one-time document. A new application can create a subdomain, a deployment can expose a service and a migration can leave the old environment online.
The goal is therefore to detect what appears, disappears or changes over time, then compare that external reality with what is expected.
See your infrastructure the way the Internet sees it
DNS records, TLS certificates, HTTP services and subdomains already reveal a meaningful part of an organisation's external exposure. Observing them from the outside can help reveal a forgotten service, an old API, an exposed staging environment or an unexpected hostname.
Before looking for the next critical vulnerability, it is worth asking a simpler question: do we really know everything we expose to the Internet?
Source
Published on September 14, 2026.