In organizations with multiple squads and deployment autonomy, it is surprisingly easy for Shadow APIs to appear: real endpoints in cloud that process data and authenticate users, but that are not in the security inventory, do not go through the “corporate” WAF, and many times not even through the review process. We’re not talking about “forgotten services” in the abstract; we’re talking about live HTTP routes that someone put into production to “get by” and that stayed.
The most common combination I see in companies: developers publish directly to API Gateway (or expose an App Engine) because it’s fast, and the security team assumes that “everything external” comes in through the central load balancer/WAF. That assumption breaks as soon as there is an alternative endpoint with its own DNS, an accessible testing stage, or a default hostname from the cloud provider.
What went wrong: the day the WAF “didn’t see anything”
The pattern usually repeats. Security receives alerts about data exfiltration or about a token used from anomalous geographies, reviews logs from the central WAF and “there’s nothing”. While the SOC chases ghosts, the attacker is hitting an endpoint that is not behind that WAF: an api-gw created by a product team, or an app in App Engine with default rules.
In a company, this translates into hours (or days) of misdirected investigation. Incident responders look where they have telemetry: CDN/WAF, corporate reverse proxy, SIEM with “standard” sources. The problem is that the Shadow API is generating traffic in another layer, with other logs and other owners. The practical result: delayed containment and decisions based on incomplete data.
In addition, these APIs often are born with “delivery-mode” decisions: partial authentication, overly broad scopes, or minimal input validations. If the endpoint was left outside central control, it was also left outside the policies that do apply to the front door: rate limiting, bot detection, anti-injection rules, and uniform traceability.
Early signals: technical clues that usually appear before the incident
Before an incident blows up, there are almost always signals. The difficulty is that they don’t appear in a single panel; they appear as small inconsistencies between inventories, DNS, and network telemetry. When you connect them, you see the “outline” of a Shadow API.
These are clues that in corporate environments tend to repeat (and it’s worth treating them as hygiene work, not as “one-off hunting”):
- Domains and subdomains that resolve to cloud provider endpoints (default hostnames or CNAME to API Gateways/managed services).
- Projects/accounts with HTTP services enabled without a clear owner or with incomplete tags (cost center, environment, data).
- Egress traffic to “own services” that are not in the catalog, detected by corporate proxy, VPC Flow Logs, or equivalent.
If you find domains that point to a “parallel” API Gateway, the real consequence is that any central WAF control is irrelevant for that traffic. In internal audits, this often ends up as a finding for “lack of compensating control” and, worse, as a monitoring gap: it’s not that the WAF fails, it’s that it was never in the path.
If the problem is ownership and tags, the risk becomes operational: nobody rotates secrets, nobody reviews IAM permissions, and nobody knows what data goes through there. In incidents, that lack of ownership translates into paralysis: it takes too long to decide whether shutting down the endpoint breaks something critical or if it’s “dead”.
Public API vs internal API exposed by SSRF: the nuance that changes the priority
Not all Shadow APIs are “public” in the classic sense. A particularly dangerous case is the internal API (intended for consumption from the private network or from internal workloads) that ends up being reachable indirectly via a vector like SSRF (Server-Side Request Forgery) from an application exposed to the Internet.
In a company, this happens when a frontend service (public) has some functionality that fetches URLs (webhooks, importers, previews, callbacks) and does not validate destinations. The attacker doesn’t need the internal API to be public; it’s enough that the frontend can call that API from its network position. In modern cloud environments, that “bridge” is common because internal network permissions are more permissive than external ones.
Practical consequence: your prioritization changes. A Shadow API “internal only” can look like low priority if you look only at direct exposure. But if there is a plausible SSRF flow, it becomes an escalation path: access to admin endpoints, metadata, configuration services, or data APIs without the controls that external traffic would have.
In real triage, it’s worth separating two questions: (1) is it accessible from the Internet? (2) if it isn’t, what exposed components could pivot to it? That second question is where many organizations fail, because their inventory of internal APIs is fuzzy and their threat modeling stays at the perimeter.
How to do it in practice: discovering Shadow APIs with Cloud Asset Inventory + enumeration
The most consistent way to discover Shadow APIs is not to “scan the Internet” blindly, but to cross cloud inventory with observable HTTP surface. In Google Cloud, Cloud Asset Inventory lets you list resources and their metadata at the organization/project level. In AWS/Azure there are equivalents, but here the operational approach is the same: inventory resources that can expose HTTP and then validate accessibility and routes.
A practical flow that works well in corporate:
- Inventory candidate resources: API Gateways, App Engine services, Cloud Run services, load balancers, Kubernetes ingress, managed endpoints. The goal isn’t perfect; it’s to have an initial “universe”.
- Normalize ownership and exposure: for each resource, capture project/account, labels, environment, associated DNS, and whether it is (or isn’t) behind the corporate WAF/proxy. Here the first 80% of Shadow APIs usually appears: “they exist but nobody registered them”.
- Enumerate real endpoints: use discovery tools (for example, solutions like Gorky/APISec or other API inventory/discovery equivalents) to detect routes, methods, and versions, and compare them with what the team believes exists (OpenAPI/Swagger in repos, internal catalogs, etc.).
Inventorying is not enough if you don’t move on to verification. In practice, verification means: resolve DNS, review certificates/TLS, identify provider default hostnames, and confirm what responds. It is common to find “dev” or “test” stages without robust auth or with API keys embedded in internal clients.
Where Cloud Asset Inventory provides the most value is in coverage: even if the endpoint doesn’t have “nice” public DNS, the resource exists and leaves a trace. Enumeration (with specialized tools) provides the other half: what routes exist and what behavior they expose. That combination is what turns “we have resources” into “we have endpoints”, which is what security needs to model risk and put controls in place.
If you need a verifiable (and auditable) technical control in Google Cloud to reduce shadowing by front door bypass, one concrete measure is to prevent, by organization policy, services from being created with public exposure outside approved patterns. An example Organization Policy policy to avoid public IPs on Compute Engine instances (it doesn’t solve everything, but it reduces parallel surface) would be:
- Restrict public IPs on VM: use the
compute.vmExternalIpAccessconstraint to deny external IP except for justified exceptions.
Validation here is not “trusting” that the policy exists: it is verifying it in the organization tree (org/folder/project), checking exceptions, and reviewing whether there are legacy resources with external IP by inheritance or by prior permissions. In parallel, you must cover managed services (API Gateway/App Engine/Cloud Run) with equivalent policies and guardrails, because public exposure does not always go through a VM IP.
Recommendations for corporate environments
Shadow APIs in cloud usually are born from delivery speed and from deployment paths alternative to the central WAF (API Gateway/App Engine/managed services). The real impact is not only “more surface”: it is loss of visibility, slower incident response, and inconsistent controls between teams.
To discover endpoints that security doesn’t even know exist, a combined approach works better: inventory with Cloud Asset Inventory to find resources capable of exposing HTTP, and route enumeration/control with API discovery tools (for example, Gorky/APISec or other equivalents in your stack). The goal is to close the gap between “deployed resources” and “accessible endpoints”, including the critical nuance of internal APIs that can become reachable via SSRF.
Operationally, what most reduces recurrence is treating it as a platform problem: mandatory ownership/tags, approved deployment paths, and verifiable policies that prevent public exposures outside the corporate pattern. If you can’t measure and list your real endpoints, you can’t defend them consistently.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.
Francisco Sepúlveda
Cloud Computing & Cybersecurity Instructor, Learning Experience Designer
Instructor and consultant in Cloud Computing, Cybersecurity and AI, with more than 25 years of hands-on experience in real enterprise environments. I design and deliver technical training programs, combining deep subject-matter expertise with learning experience design to make complex security concepts stick. I share practical, applied analysis on Cloud Security in Practice.
More about me →