Shadow APIs in Microservices: The Attack Surface Your Gateway Never Sees

Shadow APIs security is really an inventory problem first and an access-control problem second. In microservices, teams often secure the public entry point well, but still leave behind undocumented routes, old versions, debug endpoints, partner-only handlers, and internal service URLs that never appear in the gateway policy. OWASP’s API Security project calls this out directly as improper inventory management, noting that APIs often expose more endpoints than traditional web apps and that outdated documentation can leave deprecated versions and debug endpoints exposed. Istio’s gateway docs also make the boundary clear: a gateway is the edge load balancer for HTTP/TCP traffic, which means it cannot protect what it never routes.

What shadow APIs actually are

A shadow API is any API surface that exists in production, staging, or a reachable internal network path but is missing from your intended contract, documentation, or gateway policy. In practice, that includes forgotten /v1 routes, admin endpoints, mobile-app-only endpoints, health and debug handlers, old partner integrations, and service-to-service handlers exposed on separate hosts or ports. The risk is not just “unknown endpoints”; it is unknown behavior, unknown authorization, and unknown data exposure. That maps closely to OWASP API9:2023, because the real failure is that nobody has a complete, current inventory of what exists.

In microservices, shadow APIs usually appear when teams optimize for shipping speed:

• a new service launches behind the gateway, but an internal ingress or service mesh route remains reachable;
• a versioned endpoint stays alive after the frontend stops using it;
• a debug or feature-flag route is left open after a release;
• a sidecar, internal load balancer, or service-to-service path bypasses the edge controls.

That is why the attack surface is often larger than the router table. The gateway sees only the flows it terminates. The rest live in the gaps between service owners, platform teams, and deployment tooling.

Why the gateway never sees it

A gateway protects the path it owns. If a service is exposed through another listener, a direct cluster IP, a NodePort, a forgotten DNS name, a private ALB, or an internal mesh route, the gateway policy can be perfect and still miss the real path. Istio’s documentation describes a gateway as the edge of the mesh for incoming and outgoing traffic, which is useful precisely because it defines the boundary; anything outside that boundary needs separate control.

This is where teams get surprised:

• the gateway enforces JWT checks, but a legacy endpoint is still reachable internally;
• the public path is rate-limited, but direct service access is not;
• the external OpenAPI document looks clean, but the backend exposes extra handlers;
• the frontend is compliant, but the backend still returns sensitive fields through an undocumented route.

That is why shadow APIs security must include route discovery, not just perimeter policy.

Security controls that fail first

The first control to fail is often documentation. A stale OpenAPI file or incomplete route inventory gives everyone false confidence. OWASP specifically recommends proper and updated documentation, plus an inventory of hosts and deployed API versions, because deprecated versions and exposed debug endpoints are common failure modes.

Next is authorization. Teams sometimes assume that “internal” means “trusted,” but most shadow API incidents start with weak or inconsistent authorization checks. Our API security service emphasizes authentication, authorization, sensitive information handling, and documentation review as core testing areas, which is exactly the right lens here.

Rate limiting and logging are the other common blind spots. OWASP’s API guidance also highlights resource-consumption risks, which is a reminder that an undocumented endpoint can be abused just as easily as a documented one. If the endpoint is hidden from monitoring, the abuse lasts longer and is harder to triage.

How to find shadow APIs before attackers do

Start with a contract-versus-reality comparison.

Your job is to compare:

1. what the gateway and OpenAPI say should exist,
2. what the codebase and service mesh actually expose,
3. what the runtime accepts from a real request path.

A practical inventory workflow looks like this:

# 1) Export the documented surface
curl -s https://api.example.com/openapi.json \
  | jq -r '.paths | keys[]' \
  | sort > documented.txt

# 2) Export gateway routes or route manifests
kubectl get httproute,gateway -A -o json \
  | jq -r '.. | .path? // empty' \
  | sort -u > gateway.txt

# 3) Compare both lists
comm -23 documented.txt gateway.txt

Anything that appears in the runtime but not in the contract is worth reviewing. Anything that appears in the contract but not in the runtime should also be checked, because stale specs can hide abandoned endpoints or outdated auth assumptions.

For service owners, add these checks to CI:

# Example guardrail idea
name: api-surface-check
on: [pull_request]
jobs:
  compare-routes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Diff OpenAPI against deployed route manifest
        run: |
          python scripts/diff_api_surface.py \
            --openapi openapi.yaml \
            --routes gateway-routes.json

The goal is not just detection. The goal is making undocumented endpoints expensive to keep alive.

What to test on each candidate endpoint

Once you find a candidate shadow API, test it like a real attacker would:

• Does it require auth at all?
• Does it accept the same token but bypass object-level checks?
• Does it return more fields than the public API?
• Does it accept unsafe methods like PUT, PATCH, or DELETE?
• Does it expose verbose errors, stack traces, or internal hostnames?
• Can it be called directly, without the gateway?

A quick manual probe can look like this:

curl -i https://internal-api.example.com/v1/admin/export
curl -i -H "Authorization: Bearer $TOKEN" \
  https://internal-api.example.com/v1/admin/export

curl -i -X OPTIONS https://internal-api.example.com/v1/admin/export

If the direct path behaves differently from the gateway path, you have a trust-boundary inconsistency. That is often the real issue behind “we already secured the API.”

Free Website Vulnerability Scanner by Pentest Testing Corp.

Sample report by the tool to check Website Vulnerability

How to harden against shadow APIs

The fix is layered.

First, make inventory a product artifact. Every service should ship with a current route manifest, an owner, an environment label, and a deprecation date. If the team cannot answer who owns the endpoint and why it exists, the endpoint should be reviewed for removal.

Second, enforce policy at more than one layer. The gateway is necessary, but it is not sufficient. Add service-level authorization, deny-by-default routing, environment isolation, and separate controls for internal endpoints. Treat internal access as authenticated access, not safe access.

Third, make undocumented routes visible in CI. Route diffs, contract tests, and authenticated crawl tests should run before merge. That turns inventory drift into a failed build instead of a production surprise.

Fourth, review logs and telemetry for path anomalies. Hidden APIs often show up first as strange request shapes, rare response sizes, or repeated 401/403 patterns against paths nobody remembers. If you already use a central observability stack, add alerts for new paths and unusual hostnames.

Where Cyber Rely fits

For teams that want a deeper review, oUR API Penetration Testing Services align well with this problem space because the service explicitly includes authentication, authorization, rate limiting, sensitive data handling, and documentation review. That makes it a strong fit for finding undocumented endpoints, direct-access paths, and broken trust boundaries.

If the goal is to move from findings to fixes, combine that with Remediation Services so the team can turn route inventory issues into prioritized engineering work. We also support areas like Web Application Penetration Testing, Network Pentesting.

For lightweight validation, the Website Vulnerability Scanner is a useful first pass for obvious exposure and misconfiguration signals before you schedule a formal review.

Related reading from Cyber Rely

• 5 Proven CI Gates for API Security: OPA Rules You Can Ship — good follow-up for policy-as-code and route enforcement.
• Preventing Broken Access Control in RESTful APIs — useful for endpoint-level authorization patterns.
• How to Prevent SSRF in TypeScript ERP Systems — helpful when internal endpoints can be reached through server-side request paths.

Conclusion

Shadow APIs security is not about hunting for secret endpoints for the sake of it. It is about proving that your documented surface matches your real one, across gateway, mesh, and backend. If the gateway is your front door, shadow APIs are the side doors, basement windows, and forgotten keys. Fixing that visibility gap reduces exposure, improves audit readiness, and gives engineering teams a cleaner release pipeline. OWASP’s API inventory guidance and Istio’s edge-boundary model both point to the same lesson: if it is reachable, it must be inventoried, owned, and enforced.

Map internal APIs before attackers or auditors do. Start with the Free Website Vulnerability Scanner, then move to API Penetration Testing Services and Remediation Services.