Was sind API-Angriffe?

Was sind API-Angriffe?

API-Angriffe sind boesartige Versuche, ein Application Programming Interface (API) sowie die dahinterliegenden Daten und Systeme zu missbrauchen, zu stoeren oder unbefugt darauf zuzugreifen. Da moderne Web- und Mobilanwendungen ihre Geschaeftslogik groesstenteils ueber APIs bereitstellen, greifen Angreifer diese Endpunkte zunehmend direkt an. Ein Angriff reicht von einer einzelnen praeparierten 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 grosse Datenmengen offenlegt.
• Maschinenlesbar und vorhersehbar: dokumentierte Endpunkte und durchzaehlbare Objekt-IDs erleichtern automatisiertes Ausprobieren.
• Grosse Angriffsflaeche: oeffentliche, Partner- und interne APIs vervielfachen die Angriffsflaeche, vergessene Shadow APIs sind haeufig.
• Schwaechere Schutzmechanismen: ohne Browser oder CAPTCHA operieren Bots und Skripte ungehindert.

Injection und Parameter-Manipulation

Injection tritt auf, wenn nicht vertrauenswuerdige Eingaben ohne korrekte Behandlung an einen Interpreter (SQL, NoSQL, OS-Befehle) uebergeben werden und die Abfrage veraendern. Verwandt damit ist die Parameter-Manipulation, bei der Werte wie Preise oder Rollen veraendert 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-Pruefung, langlebige Tokens und ungedrosselte Login-Endpunkte. Credential Stuffing spielt zusaetzlich aus anderen Datenlecks stammende Zugangsdaten aus. Massnahmen sind kurzlebige signierte Tokens, Multi-Faktor-Authentifizierung, Erkennung kompromittierter Passwoerter und Rate Limiting an Authentifizierungs-Endpunkten.

Broken Object-Level Authorization (BOLA)

BOLA, auch IDOR genannt, entsteht, wenn ein Endpunkt ein Objekt anhand einer ID zurueckgibt, ohne zu pruefen, ob der Aufrufer darauf zugreifen darf. Aus /api/v1/orders/1001 wird /api/v1/orders/1002 und liefert die Bestellung eines anderen Kunden. Die Loesung ist eine Besitzpruefung bei jeder Anfrage, idealerweise ueber eine zentrale Autorisierungsschicht.

Uebermaessige Datenexposition

APIs geben oft mehr Felder zurueck als noetig und verlassen sich darauf, dass das Frontend sie verbirgt. Angreifer lesen die Rohantwort und sammeln interne IDs, Rollen oder personenbezogene Daten. Geben Sie ueber explizite Antwort-Schemas nur die Felder zurueck, 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) ueberflutet Endpunkte mit Anfragen, bis CPU, Speicher oder Datenbank erschoepft sind. Kontrollen sind Rate Limiting pro Client und Endpunkt, Quotas, Groessenlimits sowie Schutz durch WAF oder CDN. Zu pruefen, ob diese Limits unter Last halten, ist eine Form von Last- und Performance-Testing: Sie erzeugen bewusst hohen, gleichzeitigen Verkehr, um die Stabilitaet der API zu bestaetigen.

Man-in-the-Middle und Server-Side Request Forgery

Man-in-the-Middle (MITM)-Angriffe fangen den Verkehr ab; durchgehendes TLS, HSTS und Zertifikatspruefung 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 fuer ausgehende Ziele, das Blockieren interner IP-Bereiche und die Validierung nutzergelieferter URLs.

API-Angriffe im Ueberblick

API-Angriffe erkennen und verhindern

Erkennung setzt Sichtbarkeit voraus. Protokollieren Sie jede Anfrage und achten Sie auf Fehlerraten-Spitzen, ungewoehnliche 401- und 403-Muster, Verkehrsspitzen einzelner Clients und sequentielle ID-Aufzaehlung. Kontinuierliches API-Monitoring aus mehreren Standorten legt eine Basislinie fest, sodass Anomalien auffallen und Alarme die Reaktionszeit verkuerzen. Praevention heisst: jede Anfrage zentral authentifizieren und autorisieren, alle Eingaben validieren, Rate Limiting und Quotas anwenden, im Transit mit TLS und HSTS verschluesseln, 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 haeufigste Art von API-Angriff?

Broken Object-Level Authorization (BOLA, auch IDOR) gehoert zu den haeufigsten API-Fehlern. Ein Angreifer greift auf fremde Daten zu, indem er eine ID in der Anfrage aendert, wenn der Server den Besitz nicht prueft.

Wie unterscheiden sich API-Angriffe von klassischen Web-Angriffen?

Sie zielen auf Maschine-zu-Maschine-Endpunkte, die strukturierte Daten direkt zurueckgeben, 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 bestaetigen, 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 veroeffentlichte Industriereferenz, die die kritischsten API-spezifischen Risiken einordnet und als Checkliste bei Design, Entwicklung und Sicherheitspruefung dient.

Woran erkenne ich, dass meine API angegriffen wird?

Achten Sie auf Anomalien gegenueber einer Basislinie: Verkehrsspitzen einzelner Clients, erhoehte Fehler- und 401- oder 403-Raten, sequentielle ID-Aufzaehlung und Latenzverschlechterung. Kontinuierliches Monitoring macht diese Signale schnell sichtbar.