Ein einzelnes Werkzeug macht eine API nicht sicher. Wirksam ist erst das Zusammenspiel aus Sichtbarkeit, kontinuierlichem Testen und Durchsetzung, jede Stufe deckt eine Lücke der anderen ab.

1. CISpec-Diffing: neue, nicht reviewte Routen brechen den Build
→
2. LaufzeitDiscovery: realer Traffic gegen die freigegebene Spec
→
3. GatewayDefault-Deny: nur freigegebene Pfade, Schema geprüft

Drei Schichten, ein Ziel: kein Endpunkt in Produktion, den niemand kennt und niemand prüft.

1. Den Bestand kennen

Sicherheit beginnt mit Sichtbarkeit. Eine Schutzmaßnahme, eine Authentifizierungsprüfung oder ein Rate-Limit greift nur für Endpunkte, von denen das Sicherheitsteam überhaupt weiss. OWASP beschreibt im Risiko API9:2023 Improper Inventory Management genau diese Lücke: Wer mehrere API-Versionen und -Umgebungen betreibt, braucht nicht nur ein gutes Verständnis der eigenen APIs und Endpunkte, sondern auch davon, wie diese Daten mit Dritten teilen. Fehlt das, entsteht laut OWASP ein documentation blindspot und ein data flow blindspot.

Der typische Auslöser ist die stille Drift zwischen Code und Dokumentation. Die OpenAPI-Spezifikation beschreibt den Soll-Zustand zu einem Zeitpunkt, der laufende Dienst entwickelt sich aber weiter. Jeder Hotfix, jede neue Route, jeder vergessene Deprecation-Plan vergrößert den Abstand. Genau hier setzen drei Kategorien an, die im realen Verkehr auftauchen, aber nicht in Spec, Ticket oder Review stehen:

  • Shadow-APIs: Laut Wallarm undokumentierte Endpunkte, die ohne ordentliche Freigabe oder Aufsicht in der Infrastruktur existieren. Technisch ist eine Shadow-API ein Endpunkt, der im tatsächlichen Datenverkehr auftaucht, aber nicht in der hinterlegten Spezifikation steht.
  • Zombie-APIs: Veraltete, eigentlich abgekündigte Endpunkte, von denen alle annehmen, sie seien abgeschaltet, die aber weiterlaufen. OWASP nennt als Szenario einen Beta-Host, der dieselbe Logik wie die Produktion führt, jedoch ohne das vorgelagerte Rate-Limit, sodass sich Reset-Token per Brute Force erraten lassen.
  • Phantom- und KI-generierte Endpunkte: Routen, die von Code-Assistenten oder Scaffolding-Tools mitgeneriert werden und nie durch Spezifikation, Ticket oder Review gegangen sind. Sie verschärfen die Drift, weil Code schneller entsteht, als ihn die Governance erfassen kann.

Das ist kein Randthema. Salt Security berichtet im State of API Security Report 2025, dass 99 Prozent der Organisationen im vergangenen Jahr API-Sicherheitsprobleme hatten und bei einem Viertel der Befragten der API-Bestand binnen eines Jahres um mehr als 100 Prozent wuchs. Zugleich fehlt einem Drittel der Befragten das Vertrauen, KI-getriebene Bedrohungen zu erkennen.

Die zentrale Konsequenz: Der Dokumentation allein darf man nicht vertrauen. OWASP empfiehlt, alle API-Hosts und integrierten Dienste samt Umgebung, Zugriffskreis, Version und Datenfluss zu inventarisieren, die Dokumentation automatisiert aus offenen Standards zu erzeugen und in die CI/CD-Pipeline einzubauen. Genauso wichtig: keine Produktionsdaten in Nicht-Produktions-Deployments, und Schutzmaßnahmen für alle exponierten Versionen, nicht nur die aktuelle Produktion.

Der wirksame Ansatz ist kontinuierliche Laufzeit-Discovery: Man vergleicht den realen Datenverkehr fortlaufend mit der hinterlegten Spezifikation. Wallarm definiert Shadow-APIs als Endpunkte, die im Traffic auftauchen, aber in der Spec fehlen, und Zombie-APIs über den Vergleich verschiedener Spec-Versionen. Erkannte Abweichungen werden als Befund markiert und können direkt an SIEM oder SOAR gemeldet werden. So wird die Spezifikation vom blinden Vertrauensanker zum laufend abgeglichenen Soll-Ist-Instrument.

GET /users -> type_of_endpoint: shadow

  1. Befund: Endpunkt erscheint im Live-Traffic, fehlt aber in Specification-01.
  2. Folge: keine Auth-Prüfung, kein Rate-Limit, kein Monitoring greift.

Beispiel eines Discovery-Befunds (nach Wallarm): ein im Verkehr beobachteter Endpunkt, der in keiner Spezifikation steht, wird automatisch als Shadow-API markiert.

2. Das Richtige testen, kontinuierlich

Die häufigsten API-Risiken sind keine klassischen Angriffe mit erkennbaren Mustern, sondern Logik- und Berechtigungsfehler. Bei Broken Object Level Authorization (BOLA, API1:2023) manipuliert ein Angreifer schlicht die ID eines Objekts in Pfad, Query, Header oder Payload. Der Request selbst ist technisch völlig legitim. Ein Signatur- oder Mustererkenner sieht hier nichts Auffälliges, denn die Anfrage entspricht exakt dem erwarteten Format. Verletzt wird die Regel, dass dieser Nutzer dieses Objekt nicht sehen darf, und diese Regel kennt nur die Anwendung selbst.

Das Gleiche gilt für Broken Function Level Authorization (BFLA, API5:2023): Ein regulärer Nutzer ruft eine administrative Funktion auf, etwa durch Wechsel der HTTP-Methode (GET zu DELETE) oder durch Raten eines Endpunkts wie /api/v1/users/export_all. Auch das sind syntaktisch korrekte API-Calls. OWASP hält ausdrücklich fest, dass man nicht aus dem URL-Pfad ableiten darf, ob ein Endpunkt regulär oder administrativ ist.

Warum Signaturen nicht genügen: BOLA und BFLA sind kontextabhängig. Ob ein Zugriff erlaubt ist, ergibt sich aus Nutzeridentität, Rolle, Hierarchie und Objektbesitz, nicht aus der Form des Requests. Den richtigen Test muss man deshalb aktiv formulieren:

  • Aktiv prüfen, nicht nur erkennen: Kann Nutzer A auf das Objekt von Nutzer B zugreifen? Kann ein normaler Nutzer eine Admin-Funktion auslösen? Solche Fälle muss man gezielt durchspielen.
  • Default-Deny: OWASP empfiehlt für BFLA, dass die Zugriffslogik standardmäßig alles verweigert und nur explizit pro Rolle freigibt.
  • Tiefenanalyse der Autorisierung entlang von Rollen, Gruppen und Sub-Nutzern statt punktueller Prüfung.

Warum jährlich nicht reicht: OWASP formuliert es im Kapitel für DevSecOps unmissverständlich: "Scanning and penetration testing yearly are no longer enough." APIs ändern sich mit jedem Deploy. Ein im Januar geprüfter Endpunkt kann im Februar einen neuen Parameter, eine neue Methode oder eine neue Rolle haben, und damit eine neue Lücke. Ein Befund von vor zwölf Monaten sagt nichts über den heute ausgelieferten Stand aus.

Shift-Left, Tests in CI/CD: OWASP fordert continuous security testing across the entire software development life cycle und Sicherheitsautomatisierung in der Pipeline, ohne die Entwicklungsgeschwindigkeit zu bremsen. Konkret nennt OWASP für BOLA als Präventionsmaßnahme: Tests schreiben, die die Autorisierung prüfen, und Änderungen nicht ausliefern, wenn diese Tests fehlschlagen. Genau das ist Shift-Left: die Berechtigungsprüfung wird zum Quality Gate im Deploy.

Reproduzierbare Befunde mit Protokoll: OWASP betont, Findings zeitnah und in den Werkzeugen der Entwickler zu liefern, nicht als PDF, und sie mit einem konkreten Angriffsszenario greifbar zu machen. Ein Befund braucht den exakten Request, die manipulierte ID oder Methode und die beobachtete Antwort, damit er reproduzierbar bleibt und im Regressionstest dauerhaft abgesichert wird.

Plus kontinuierliche Laufzeitprüfung: Pipeline-Tests prüfen den bekannten, deklarierten Stand. Die NIST-Publikation SP 800-204D beschreibt, wie Sicherheitsmaßnahmen direkt in die CI/CD-Phasen Build, Test, Package und Deploy integriert werden. Da aber undokumentierte oder veraltete Endpunkte (OWASP API9:2023, Improper Inventory Management) durch reine Pipeline-Tests durchrutschen, braucht es ergänzend eine laufende Prüfung in der Produktion. Test in CI/CD und Laufzeitüberwachung decken zusammen sowohl den geplanten als auch den real exponierten Stand ab.

Szenario BOLA (aus OWASP API1:2023): Eine E-Commerce-Plattform liefert Umsatzcharts über den Endpunkt /shops/{shopName}/revenue_data.json.

  1. Der Angreifer liest über einen anderen Endpunkt die Liste aller Shop-Namen aus und ersetzt per Skript {shopName} reihenweise.
  2. Da der Server nicht prüft, ob der eingeloggte Nutzer Inhaber des Shops ist, erhält der Angreifer die Verkaufsdaten tausender Shops.
  3. Der einzige Schutz: ein Test, der genau diesen Cross-Tenant-Zugriff aktiv durchspielt und bei Erfolg den Deploy blockiert.

BOLA in der Praxis: ein technisch legitimer Request, den nur ein logikbasierter Test als Verletzung erkennt

3. Durchsetzen am Gateway

Das API-Gateway ist der zentrale Punkt, an dem Querschnitts-Policies einmal definiert und für alle dahinterliegenden Dienste durchgesetzt werden, statt sie in jedem Microservice zu wiederholen. Typische Gateway-Funktionen sind Authentifizierung und Autorisierung, Rate Limiting gegen unbeschränkten Ressourcenverbrauch, Schema-Validierung und mTLS zwischen Komponenten. Kong etwa bildet diese Funktionen als Plugins ab, die pro Service oder Route gebunden werden, darunter ein dediziertes Rate-Limiting-Plugin.

Der entscheidende Grundsatz ist Default-Deny: nicht explizit freigegebene Pfade werden abgelehnt, nicht stillschweigend durchgereicht. Das deckt sich mit Zero Trust nach NIST SP 800-207, wo kein impliziter Zugriff allein aufgrund der Netzwerklage gewährt wird, sondern Authentifizierung und Autorisierung als eigenständige Funktionen vor jedem Zugriff anhand von Identität und Policy entschieden werden. CISA führt Zero Trust über ein Reifegradmodell mit fünf Säulen und drei übergreifenden Fähigkeiten ein, das schrittweise von statischen zu dynamischen, kontextbasierten Entscheidungen führt.

Wichtige Grenze: Ein Gateway schützt nur bekannte Routen. Ist eine alte API-Version, ein Test- oder Schatten-Endpunkt nicht am Gateway registriert, greift auch keine Policy. Genau das beschreibt OWASP als API9:2023 Improper Inventory Management: alte, ungepatchte Versionen und undokumentierte Hosts vergrößern die Angriffsfläche, sind per Google-Dorking oder DNS-Enumeration auffindbar und umgehen die zentralen Kontrollen. Discovery (vollständiges, aktuelles Inventar aller Endpunkte) ist damit Voraussetzung für jede Gateway-Durchsetzung.

Eine mehrschichtige Pipeline schließt die Lücke zwischen Spec und Realität:

  • CI-Layer (Spec-Diffing): Jede Änderung wird gegen die freigegebene OpenAPI-Spec geprüft. Neue, nicht reviewte Routen lassen den Build fehlschlagen, bevor sie ausgeliefert werden. Das adressiert OWASP API9 (aktuelle Dokumentation, Retirement-Plan je Version) und API8:2023 Security Misconfiguration.
  • Laufzeit-Layer: Tatsächlicher Traffic wird gegen die freigegebene Spec abgeglichen. Pfade, die antworten, aber nicht spezifiziert sind (Shadow- oder Zombie-APIs), lösen Alarm aus. Das füttert das Inventar mit Funden, die statische Reviews übersehen.
  • Gateway-Layer: Default-Deny, Schema-Validierung und gateway-seitige Auth erzwingen die freigegebene Spec im Datenpfad. Was nicht in der Spec steht, wird abgewiesen.

Die drei Schichten greifen ineinander: CI verhindert, dass undokumentierte Routen entstehen; die Laufzeit findet, was trotzdem auftaucht; das Gateway setzt Default-Deny durch. So wird OWASP-Top-10-Abdeckung wie Broken Authentication (API2), Broken Function Level Authorization (API5) und Unrestricted Resource Consumption (API4) nicht nur dokumentiert, sondern technisch erzwungen.

CI-Gate (OpenAPI-Diff)
CI-Gate: build fails wenn Traffic-Spec von der freigegebenen OpenAPI abweicht
$ openapi-diff approved-spec.yaml ./build/generated-spec.yaml --fail-on-incompatible
ERROR: 2 undokumentierte Routen gefunden, nicht reviewt:
  + POST /internal/v1/users/{id}/impersonate
  + GET  /v0/legacy/export        (deprecated, kein Retirement-Plan)
Build abgebrochen (exit 1) - Route am Gateway nicht freigegeben -> Default-Deny

Beispielhaftes CI-Spec-Diffing: nicht reviewte oder veraltete Routen brechen den Build, bevor sie am Gateway freigegeben werden.

Mehr zur zentralen Durchsetzungsebene: API Gateways. Warum der Bestand die Voraussetzung ist: Improper Inventory (API9).

Quellen

Weiterlesen
DurchsetzungAPI Gateways RisikoImproper Inventory (API9) WarumWarum API Security