OWASP-Einstufung (API9:2023)

OWASP-Einstufung: API Specific. Exploitability: Easy (2). Prevalence: Widespread (3). Detectability: Average (2). Technical Impact: Moderate (2). Business Impact: Specific (organisations-/anwendungsspezifisch). (Alle Werte 1:1 von der offiziellen OWASP-Seite bestätigt.)

Wie der Angriff funktioniert

Moderne Architekturen wie Microservices, Cloud und Kubernetes machen es leicht, viele API-Hosts und mehrere API-Versionen parallel auszurollen. Dadurch entstehen zwei Blindspots.

  • Dokumentations-Blindspot: Es ist unklar, in welcher Umgebung ein API-Host läuft (Produktion, Staging, Test, Entwicklung), wer Netzwerkzugriff haben sollte (öffentlich, intern, Partner) und welche Version aktiv ist. Meist liegt das daran, dass Dokumentation fehlt oder veraltet ist, es keinen Stilllegungsplan (Retirement) gibt und das Host-Inventar lückenhaft ist.
  • Datenfluss-Blindspot: Sensible Daten fließen ohne geschäftliche Rechtfertigung, Freigabe oder Sichtbarkeit an Dritte.

Angreifer finden vergessene oder alte Endpunkte mit einfachen Mitteln wie Google Dorking, DNS-Enumeration und spezialisierten Suchmaschinen für ans Internet angeschlossene Geräte oder Server. Diese Endpunkte sind oft ungepatcht und haben schwächere Sicherheitsanforderungen als die aktuelle Produktionsversion.

Häufig hängen mehrere API-Versionen oder Deployments an derselben Datenbank mit echten Daten. Dadurch legt eine Lücke in einer alten Version echte Produktionsdaten frei.

1. AusgangslageAlte oder undokumentierte API läuft weiter (v1, staging)
→
2. AngriffAngreifer findet den vergessenen Endpunkt
→
3. ErgebnisZugriff über die ungepatchte Schatten-API

Vergessene und undokumentierte APIs sind ein Einfallstor.

Beispiel

OWASP-Szenario #1 (Beta-Host ohne Rate-Limiting):

  1. Ein soziales Netzwerk schützt die Passwort-Zurücksetzung gegen Brute Force per Rate-Limiting. Dieses Limit ist NICHT im API-Code selbst, sondern in einer separaten, vorgelagerten Komponente zwischen Client und offizieller API (api.socialnetwork.owasp.org) umgesetzt.
  2. Ein Forscher entdeckt einen Beta-API-Host: beta.api.socialnetwork.owasp.org.
  3. Dieser Beta-Host führt denselben API-Code aus - inklusive des Passwort-Reset-Mechanismus - aber OHNE die vorgelagerte Rate-Limiting-Komponente.
  4. Da kein Rate-Limiting greift, kann der Forscher per einfacher Brute Force den 6-stelligen Reset-Token durchprobieren und so das Passwort eines beliebigen Nutzers zurücksetzen und das Konto übernehmen.

Hinweis: Der OWASP-Text beschreibt nur diesen Ablauf; konkrete Endpunkt-Pfade oder JSON-Payloads sind dort nicht angegeben.

Auswirkung

Angreifer erlangen Zugriff auf sensible Daten oder übernehmen sogar den Server. Da unterschiedliche API-Versionen oder Deployments oft an derselben Datenbank mit echten Daten hängen, kann eine Lücke in einer vergessenen Version direkt zu echten Daten führen.

Über veraltete (deprecated) Endpunkte können Angreifer Administrationsfunktionen erreichen oder bekannte Schwachstellen ausnutzen.

Beim Datenfluss-Blindspot (OWASP-Szenario #2) erlangte eine Beratungsfirma über eine zu offene Drittanbieter-Integration mit Zustimmung von 270.000 Nutzern Zugriff auf die privaten Daten von 50.000.000 Nutzern und verkaufte diese später für böswillige Zwecke.

Geschäftsfolgen: Datenschutzverletzungen, Account-Übernahmen sowie Compliance- und Reputationsschäden.

So schützt man sich

  • Alle API-Hosts inventarisieren und je Host wichtige Aspekte dokumentieren: Umgebung (Produktion, Staging, Test, Entwicklung), wer Netzwerkzugriff haben sollte (öffentlich, intern, Partner) und die API-Version.
  • Integrierte Services/Drittanbieter inventarisieren und wichtige Aspekte dokumentieren: ihre Rolle im System, die ausgetauschten Daten (Datenfluss) und deren Sensitivität.
  • Alle Aspekte der API dokumentieren: Authentifizierung, Fehler, Redirects, Rate-Limiting, CORS-Policy sowie Endpunkte inkl. Parameter, Requests und Responses.
  • Dokumentation automatisch über offene Standards generieren und den Doku-Build in die CI/CD-Pipeline integrieren.
  • API-Dokumentation nur für berechtigte API-Nutzer zugänglich machen.
  • Externe Schutzmaßnahmen (API-spezifische Sicherheitslösungen) für ALLE exponierten API-Versionen einsetzen, nicht nur für die aktuelle Produktionsversion.
  • Keine Produktionsdaten in Nicht-Produktions-Deployments verwenden; ist das unvermeidbar, müssen diese Endpunkte dieselbe Sicherheitsbehandlung wie Produktion erhalten.
  • Wenn neuere API-Versionen Sicherheitsverbesserungen enthalten, eine Risikoanalyse für die alten Versionen durchführen (z. B. Backport ohne Kompatibilitätsbruch möglich? oder alte Version schnell abschalten und alle Clients zur neuesten Version zwingen).

Phantom- und KI-generierte APIs

Neben Shadow- und Zombie-APIs verschärft eine neue Quelle das Inventarproblem: Phantom-APIs, also Routen, Handler und Parameter, die in Produktion laufen, aber nie in einer Spezifikation, einem Ticket oder einem Review auftauchten. Zunehmend entstehen sie als Nebenprodukt von KI-Codegeneratoren und Scaffolding-Werkzeugen, die plausibel wirkende Endpunkte mitgenerieren, etwa einen Admin- oder Debug-Pfad, weil dieses Muster in den Trainingsdaten normal aussah.

Das verschärft die stille Drift zwischen Code und Dokumentation, weil Code schneller entsteht, als ihn die Governance erfassen kann. Laut Salt Security berichteten 99 Prozent der Organisationen im vergangenen Jahr von API-Sicherheitsproblemen, und bei einem erheblichen Teil wuchs der API-Bestand stark. Die Antwort ist dieselbe wie bei Shadow- und Zombie-APIs, nur dringlicher: der Dokumentation nicht blind vertrauen, sondern den realen Datenverkehr kontinuierlich gegen die freigegebene Spezifikation abgleichen und jeden nicht spezifizierten Pfad als Befund behandeln.

Die Begriffe im Überblick

Die Bezeichnungen überlappen und werden herstellerübergreifend uneinheitlich benutzt. Sauber trennen lassen sie sich entlang weniger Fragen: Läuft der Endpunkt real in Produktion? Ist er in einer Spezifikation erfasst? Kennt ihn die Governance? Hat er noch einen Owner? Und wie ist er entstanden?

BegriffWas es istWorin es sich unterscheidet
Shadow / SchattenLäuft produktiv, steht aber in keinem Inventar und ist der Governance unbekannt.Am Prozess vorbei gebaut. Der Erbauer kennt sie, nur die Security nicht.
UndokumentiertEndpunkt ohne aktuelle Spezifikation.Keine eigene Kategorie, sondern das definierende Merkmal einer Schatten-API.
PhantomTauchte nie in Spec, Ticket oder Review auf, zunehmend von KI-Codegeneratoren mitgebaut.Wurde nie bewusst geplant, war in niemandes Bewusstsein. Abgrenzung zu Shadow, die jemand absichtlich baute.
Orphan / verwaistLäuft weiter, aber das verantwortliche Team ist weg.Kein Sichtbarkeits-, sondern ein Owner-Problem. Kann durchaus noch dokumentiert sein.
ZombieAlte, abgelöste Version, die nie abgeschaltet wurde und weiter Verkehr empfängt.Ein nicht abgeschalteter deprecated-Endpunkt. Decommissioning-Versagen statt verlorenem Owner.
DeprecatedOffiziell als veraltet markierte, dokumentierte Version, idealerweise mit Sunset-Plan.Der einzige gewollte Lifecycle-Status. Wird zur Zombie-API, wenn die Abschaltung ausbleibt.
RogueUnautorisiert oder absichtlich an der Governance vorbei betrieben.Einziger Begriff mit Bezug zu Böswilligkeit. Manche Hersteller nutzen ihn als Dachbegriff für Shadow und Zombie.

Die Branche definiert diese Begriffe uneinheitlich. "Phantom" etwa steht je nach Quelle für reale, unbekannte Produktionsrouten oder für halluzinierte, gar nicht existierende Schnittstellen in KI-Code. Entscheidend ist nicht das Etikett, sondern der Abgleich des realen Verkehrs gegen die freigegebene Spezifikation.

Quellen

Weiterlesen
ÜbersichtOWASP API Security Top 10 API10Unsafe Consumption of APIs