Was sind API-Angriffe?
Was API-Angriffe sind, gängige Typen wie Injection, BOLA, DDoS und Credential Stuffing, und wie man sie erkennt und verhindert.
Was sind API-Angriffe?
API-Angriffe sind bösartige Versuche, ein Application Programming Interface (API) sowie die dahinterliegenden Daten und Systeme zu missbrauchen, zu stören oder unbefugt darauf zuzugreifen. Da moderne Web- und Mobilanwendungen ihre Geschäftslogik größtenteils über APIs bereitstellen, greifen Angreifer diese Endpunkte zunehmend direkt an. Ein Angriff reicht von einer einzelnen präparierten Anfrage bis zu einer Datenflut, die einen ganzen Dienst lahmlegt.
Warum APIs bevorzugte Ziele sind
- Direkter Zugriff auf Daten und Logik: APIs liefern strukturierte Daten oft direkt aus Datenbanken, sodass ein Fehler große Datenmengen offenlegt.
- Maschinenlesbar und vorhersehbar: dokumentierte Endpunkte und durchzählbare Objekt-IDs erleichtern automatisiertes Ausprobieren.
- Große Angriffsfläche: öffentliche, Partner- und interne APIs vervielfachen die Angriffsfläche, vergessene Shadow APIs sind häufig.
- Schwächere Schutzmechanismen: ohne Browser oder CAPTCHA operieren Bots und Skripte ungehindert.
Injection und Parameter-Manipulation
Injection tritt auf, wenn nicht vertrauenswürdige Eingaben ohne korrekte Behandlung an einen Interpreter (SQL, NoSQL, OS-Befehle) übergeben werden und die Abfrage verändern. Verwandt damit ist die Parameter-Manipulation, bei der Werte wie Preise oder Rollen verändert werden, denen der Server vertraut. Schutz bieten konsequente Eingabevalidierung, parametrisierte Abfragen und minimale Datenbankrechte; bauen Sie Abfragen nie durch Verketten roher Werte.
Broken Authentication und Credential Stuffing
Ist die Authentifizierung schwach, geben sich Angreifer als legitime Nutzer aus. Typische Fehler sind unzureichende Token-Prüfung, langlebige Tokens und ungedrosselte Login-Endpunkte. Credential Stuffing spielt zusätzlich aus anderen Datenlecks stammende Zugangsdaten aus. Maßnahmen sind kurzlebige signierte Tokens, Multi-Faktor-Authentifizierung, Erkennung kompromittierter Passwörter und Rate Limiting an Authentifizierungs-Endpunkten.
Broken Object-Level Authorization (BOLA)
BOLA, auch IDOR genannt, entsteht, wenn ein Endpunkt ein Objekt anhand einer ID zurückgibt, ohne zu prüfen, ob der Aufrufer darauf zugreifen darf. Aus /api/v1/orders/1001 wird /api/v1/orders/1002 und liefert die Bestellung eines anderen Kunden. Die Lösung ist eine Besitzprüfung bei jeder Anfrage, idealerweise über eine zentrale Autorisierungsschicht.
Übermäßige Datenexposition
APIs geben oft mehr Felder zurück als nötig und verlassen sich darauf, dass das Frontend sie verbirgt. Angreifer lesen die Rohantwort und sammeln interne IDs, Rollen oder personenbezogene Daten. Geben Sie über explizite Antwort-Schemas nur die Felder zurück, die jeder Consumer wirklich braucht, statt ganze Objekte zu serialisieren.
Rate-Limit-Missbrauch, DoS und DDoS
Ein Denial-of-Service (DoS) oder seine verteilte Form (DDoS) überflutet Endpunkte mit Anfragen, bis CPU, Speicher oder Datenbank erschöpft sind. Kontrollen sind Rate Limiting pro Client und Endpunkt, Quotas, Größenlimits sowie Schutz durch WAF oder CDN. Zu prüfen, ob diese Limits unter Last halten, ist eine Form von Last- und Performance-Testing: Sie erzeugen bewusst hohen, gleichzeitigen Verkehr, um die Stabilität der API zu bestätigen.
Man-in-the-Middle und Server-Side Request Forgery
Man-in-the-Middle (MITM)-Angriffe fangen den Verkehr ab; durchgehendes TLS, HSTS und Zertifikatsprüfung halten Daten vertraulich. Server-Side Request Forgery (SSRF) bringt eine API dazu, eine vom Angreifer gelieferte URL abzurufen und interne Dienste oder Cloud-Metadaten zu erreichen. Schutz bieten Allowlists für ausgehende Ziele, das Blockieren interner IP-Bereiche und die Validierung nutzergelieferter URLs.
API-Angriffe im Überblick
| Angriffsart | Funktionsweise | Wichtigste Maßnahme |
|---|---|---|
| Injection | Eingabe verändert die Abfrage | Parametrisierte Abfragen und Validierung |
| Broken Authentication | Schwache Tokens werden missbraucht | Kurzlebige Tokens, MFA, Drosselung |
| BOLA / IDOR | Objektzugriff per ID ohne Besitzprüfung | Autorisierung bei jeder Anfrage |
| Datenexposition | Antwort verrät zu viele Felder | Explizite Schemas, Feldfilterung |
| Rate-Limit-Missbrauch / DDoS | Verkehrsflut erschöpft Kapazität | Rate Limiting, Quotas, WAF, Load-Testing |
| Credential Stuffing | Geleakte Passwörter am Login wiederholt | MFA, adaptive Limits |
| MITM | Verkehr wird abgefangen | TLS überall, HSTS, Zertifikatsprüfung |
| SSRF | Server ruft Angreifer-URLs ab | Allowlists, interne Bereiche sperren |
API-Angriffe erkennen und verhindern
Erkennung setzt Sichtbarkeit voraus. Protokollieren Sie jede Anfrage und achten Sie auf Fehlerraten-Spitzen, ungewöhnliche 401- und 403-Muster, Verkehrsspitzen einzelner Clients und sequentielle ID-Aufzählung. Kontinuierliches API-Monitoring aus mehreren Standorten legt eine Basislinie fest, sodass Anomalien auffallen und Alarme die Reaktionszeit verkürzen. Prävention heißt: jede Anfrage zentral authentifizieren und autorisieren, alle Eingaben validieren, Rate Limiting und Quotas anwenden, im Transit mit TLS und HSTS verschlüsseln, ein WAF und API-Gateway einsetzen und unter Last testen. Die meisten Risiken entsprechen der OWASP API Security Top 10, die als Checkliste bei Design und Code-Review dient.
FAQ zu API-Angriffen
Was ist die häufigste Art von API-Angriff?
Broken Object-Level Authorization (BOLA, auch IDOR) gehört zu den häufigsten API-Fehlern. Ein Angreifer greift auf fremde Daten zu, indem er eine ID in der Anfrage ändert, wenn der Server den Besitz nicht prüft.
Wie unterscheiden sich API-Angriffe von klassischen Web-Angriffen?
Sie zielen auf Maschine-zu-Maschine-Endpunkte, die strukturierte Daten direkt zurückgeben, ohne Browser oder CAPTCHA. Das macht sie leichter automatisierbar und legt Autorisierungs- und Validierungsfehler direkter offen.
Kann Rate Limiting alle API-Angriffe stoppen?
Nein. Rate Limiting ist entscheidend gegen Brute Force, Credential Stuffing und DoS, adressiert aber keine Autorisierungsfehler wie BOLA oder Injection. Wirksame Sicherheit kombiniert es mit Authentifizierung, Autorisierung, Validierung und Monitoring.
Wie hilft Load-Testing beim Schutz einer API?
Last- und Performance-Testing erzeugt kontrolliert hohen, gleichzeitigen Verkehr, um zu bestätigen, dass die API stabil bleibt, Rate Limits greifen und die Infrastruktur skaliert, bevor ein echter DoS-Versuch die Grenze findet.
Was ist die OWASP API Security Top 10?
Eine vom Open Web Application Security Project veröffentlichte Industriereferenz, die die kritischsten API-spezifischen Risiken einordnet und als Checkliste bei Design, Entwicklung und Sicherheitsprüfung dient.
Woran erkenne ich, dass meine API angegriffen wird?
Achten Sie auf Anomalien gegenüber einer Basislinie: Verkehrsspitzen einzelner Clients, erhöhte Fehler- und 401- oder 403-Raten, sequentielle ID-Aufzählung und Latenzverschlechterung. Kontinuierliches Monitoring macht diese Signale schnell sichtbar.
Verwandte Begriffe
- Was sind API-Cookies?
- API Performance Metrics: Latency, Throughput, Error Rate
- Was sind interne APIs?
- Top API Sicherheitsrisiken
- Was ist ein Payload in einer API? JSON, XML, Beispiele
- Was ist ein API-Endpoint? Definition, Beispiele, Best Practices
- Was ist ein API-Key? Definition, Use, Security Best Practices
- Was ist ein API-Security-Audit?
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um, derselben Plattform, die alles antreibt, was du gerade gelesen hast.