Shadow API - Undokumentierte und unkontrollierte API-Endpunkte - Definition & Erklärung

Shadow APIs sind API-Endpunkte die im Produktionsbetrieb aktiv sind, aber nicht offiziell dokumentiert, registriert oder durch das Sicherheitsteam überwacht werden. Sie entstehen durch veraltete Systeme, schnelle Entwicklungszyklen ohne API-Governance oder Schatten-IT-Initiativen. Da sie außerhalb normaler Sicherheitsprozesse laufen, sind sie häufig ungesichert und stellen ein erhebliches Angriffsziel dar.

Entstehung von Shadow APIs

Typische Entstehungsquellen

Legacy-Systeme:

Alte API-Version (v1, v2) bleibt aktiv nach v3-Einführung
“Wird noch von einem alten Client genutzt” → nie abgeschaltet
Undokumentiert im OpenAPI-Spec, aber im Produktionscode aktiv

Entwicklungs-Shortcuts:

Entwickler erstellt Debug-Endpoint (/api/debug/user/{id})
Geht versehentlich in Production (keine Feature-Flags)
In CI/CD Pipeline nicht als Asset erfasst

Microservices-Chaos:

Team A deployed eigenen Auth-Microservice
Nicht bei zentralem API-Gateway registriert
Direkt über Service-Discovery erreichbar

Drittanbieter-Integrationen:

SaaS-Anbieter stellt API-Callback-Endpoint bereit
Endpoint läuft auf Unternehmens-Infrastruktur
Nicht im internen API-Inventar

Mobile App Backend:

Alte App-Version (1.x) kommuniziert mit altem Backend
App nicht mehr im Store → Backend “vergessen”
API läuft still weiter, ohne Patches

Shadow API Typen

Typ	Beschreibung
Zombie APIs	Alte Versionen nie abgeschaltet
Undocumented	Existiert, aber nicht in Swagger/OpenAPI
Internal APIs	Interne Microservice-APIs von außen erreichbar
Partner APIs	B2B-Endpoints ohne gleiches Security-Level
Test APIs	Dev/Staging-Endpoints in Production

Sicherheitsrisiken

1. Fehlende Authentifizierung

Normale APIs nutzen OAuth 2.0, API-Key oder JWT. Shadow APIs sind häufig völlig ungesichert nach dem Prinzip “niemand weiß davon”:

GET /api/internal/users/list  → 200 OK + vollständige Userliste
(kein Authorization Header erforderlich!)

2. Keine Rate-Limits

Ein API-Gateway limitiert typisch 100 req/min per API-Key. Shadow APIs umgehen das Gateway vollständig - unlimitierter Zugriff, Daten-Exfiltration durch Enumeration möglich.

3. Ungepatchte Schwachstellen

Legacy-Endpoints laufen auf alten Node.js-Versionen mit bekannten CVEs. Da sie nicht im Inventar stehen, gibt es kein Patch-Management. Klassische Schwachstellen: OWASP API2:2023 - Broken Authentication, SQL Injection in alten Query-Parametern.

4. Fehlende Validierung

Neuere APIs nutzen Input Validation und Schema-Enforcement. Shadow APIs haben kein Schema - Mass Assignment ist möglich. BOLA/IDOR: /api/v1/order/{id} ohne Zugriffscheck.

5. Keine Monitoring-Abdeckung

SIEM, WAF und DAST decken nur bekannte Endpoints ab. Requests gegen Shadow APIs erzeugen keinen Alert, kein Log. Angreifer können unentdeckt agieren.

Angriffsbeispiel - API-Enumeration

# Angreifer scannt für alte API-Versionen:
for version in v1 v2 v3 v4 v5 api old legacy beta; do
  curl -s "https://target.com/api/${version}/users" \
    -o /dev/null -w "%{http_code} /api/${version}/users\n"
done

Typisches Ergebnis:

/api/v2/users: 200 OK - Shadow API gefunden!
/api/v3/users: 401 Unauthorized - produktive API, gesichert
/api/old/admin: 200 OK - kritisch!

API-Discovery und Inventarisierung

Shadow APIs aufspüren

1. Traffic-Analyse (passiv):

# Alle API-Calls aus Proxy-Logs extrahieren:
cat /var/log/nginx/access.log | \
  grep -E "^[0-9.]+ .+ \"(GET|POST|PUT|DELETE|PATCH)" | \
  awk '{print $7}' | \
  grep "^/api" | \
  sort -u > api-endpoints-found.txt

# Compare mit dokumentierten Endpoints:
diff api-endpoints-found.txt api-documented.txt

2. DAST-Discovery mit Postman/Swagger-Parser:

# Swagger/OpenAPI crawlen:
curl -s "https://target.com/swagger.json" | \
  jq -r '.paths | keys[]'
# Achtung: Shadow APIs stehen nicht in Swagger!

3. JavaScript-Source-Analyse:

# JS-Bundles auf API-Calls analysieren:
curl -s "https://target.com/app.bundle.js" | \
  grep -oE '(api|/v[0-9]+)/[a-z/{}]+' | sort -u
# Auch: Source Maps wenn öffentlich zugänglich!

4. API-Discovery-Tools:

Postman API Network (öffentlich geleakte Collections)
42Crunch API Discovery
Salt Security API Discovery
Traceable AI

5. Kubernetes Service-Discovery:

# Alle Services im Cluster auflisten:
kubectl get services --all-namespaces | grep -v kube-system
# ClusterIP-Services: intern erreichbar - von welchem Netzwerksegment?

6. Cloud-Ressourcen:

# AWS API Gateway - alle APIs:
aws apigateway get-rest-apis --query 'items[*].[name,id]'
# Unbekannte APIs im eigenen Account!

Prävention und API-Governance

API-First-Entwicklung

Jeder Endpoint wird zuerst im OpenAPI-Spec definiert
Code-Generation aus Spec (kein manuelles Schreiben)
CI/CD: API-Spec muss committet sein vor Deployment

API-Gateway als Pflicht

Alle Requests müssen über das API-Gateway laufen. Direkter Zugriff auf Backend-Services wird geblockt. Unregistrierte Paths: 404 (nicht 200!).

Kong Gateway - Catch-All für unregistrierte Paths:

plugins:
  - name: route-by-header
    config:
      rules:
        - header: X-API-Version
          upstream_url: http://backend-v3
  # Default → 404 für alles nicht Registrierte

API-Inventar automatisieren

Jeder neue Endpoint erfordert einen PR + Spec-Update + Registry-Eintrag (in Backstage oder SwaggerHub).

Backstage API-Component (catalog-info.yaml):

apiVersion: backstage.io/v1alpha1
kind: API
metadata:
  name: user-service-v3
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: openapi
  definition:
    $text: ./openapi.yaml

Deprecation-Prozess

API-Version: X-Deprecation-Date Header setzen
Sunset-Datum: 6 Monate Vorankündigung
Traffic-Monitoring: welche Clients nutzen noch die alte Version?
Hard-Remove nach Sunset-Datum (keine Ausnahmen!)

Deprecation Headers in der Response:

Sunset: Sat, 31 Dec 2026 23:59:59 GMT
Deprecation: true
Link: <https://api.example.com/v3/users>; rel="successor-version"

API-Security-Testing

Shadow APIs im Pentest finden

Automated Discovery:

# feroxbuster für API-Endpoint-Discovery:
feroxbuster -u https://api.target.com \
  -w /usr/share/wordlists/api-endpoints.txt \
  -x json \
  --filter-status 404,403 \
  --threads 50

# kiterunner (API-spezifisch):
kr scan https://api.target.com \
  -w routes-large.kite \
  --fail-status-codes 404,403,400

# Assetnote wordlists für APIs:
# https://wordlists.assetnote.io/
# best-dns-wordlist.txt für Subdomains
# aspx-large.txt, jsp-large.txt für Endpoints

Versionierung testen:

# Alle API-Versionen testen:
for v in v1 v2 v3 v4 v5 v6 v7 v8 v9 v10; do
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    "https://api.target.com/${v}/users")
  echo "${v}: ${status}"
done

JavaScript-Analyse:

# Alle API-Endpoints aus JS extrahieren:
node -e "
  const fs = require('fs');
  const content = fs.readFileSync('app.bundle.js', 'utf8');
  const matches = content.match(/['\"]\/api\/[^'\"]+['\"][^;]*/g);
  console.log([...new Set(matches)].join('\n'));
"