API Security Testing: Praxis-Guide für REST und GraphQL APIs

APIs sind das unsichtbare Rückgrat moderner Applikationen - und eine der häufigsten Angriffsquellen. Laut Gartner waren APIs 2024 der häufigste Angriffsvektor für Web-Applikationen. API Security Testing erfordert andere Methoden als klassisches Web-Testing: APIs haben keine sichtbare UI, ermöglichen direkte Daten-Zugriffe und leiden unter API-spezifischen Schwachstellen wie BOLA (Broken Object Level Authorization) und Mass Assignment.

OWASP API Security Top 10 (2023)

Nr.	Schwachstelle	Kurzbeschreibung
API1	Broken Object Level Authorization (BOLA)	Angreifer manipuliert IDs um fremde Objekte zuzugreifen
API2	Broken Authentication	Schwache Tokens, kein Rate-Limiting auf Login
API3	Broken Object Property Level Authorization	Mass Assignment, Daten-Exposition in Responses
API4	Unrestricted Resource Consumption	Kein Rate-Limiting → DoS, Account Enumeration
API5	Broken Function Level Authorization (BFLA)	Normaler User kann Admin-Endpunkte aufrufen
API6	Unrestricted Access to Sensitive Business Flows	Logik-Fehler in Workflows (Bulk-Kauf, Wiederverwendung)
API7	Server Side Request Forgery (SSRF)	API ruft interne Ressourcen auf Angreifer-Anweisung auf
API8	Security Misconfiguration	Debug-Endpunkte, CORS-Fehlkonfiguration, verbose Errors
API9	Improper Inventory Management	Shadow-APIs, undokumentierte v1-Endpunkte vergessen
API10	Unsafe Consumption of APIs	API vertraut Antworten von Drittanbieter-APIs blind

Reconnaissance: API-Endpunkte entdecken

OpenAPI/Swagger-Dokumentation finden

Der erste Schritt ist die Suche nach vorhandener API-Dokumentation. Häufige Pfade, die oft vergessen werden, öffentlich erreichbar zu lassen: /swagger-ui.html, /api-docs, /swagger.json, /openapi.json, /v2/api-docs, /api/v1/swagger und /docs. Diese können mit ffuf automatisiert abgefragt werden.

API-Versionierung prüfen

Ein häufig übersehener Angriffsvektor: Ältere API-Versionen sind oft schlechter abgesichert als aktuelle. /api/v1/users kann offen sein, während /api/v2/users korrekt geschützt ist. Versionierungslose Pfade wie /api/users haben manchmal weniger Schutzmechanismen als versionierte Endpunkte.

Weitere Discovery-Methoden

JavaScript-Dateien enthalten häufig direkte API-Aufrufe und sind eine ergiebige Quelle für undokumentierte Endpunkte (Tools: LinkFinder, Postman Interceptor). In Burp Suite lassen sich API-Pfade über Target → Site Map aus dem Browser-Traffic extrahieren. Bei mobilen Apps lohnt sich das Decompilieren der APK mit apktool und anschließende Suche nach API-URLs.

API1: Broken Object Level Authorization (BOLA)

BOLA ist die häufigste und kritischste API-Schwachstelle. Das Grundprinzip: Eine API prüft zwar, ob ein Nutzer eingeloggt ist, nicht aber ob er auf das angefragte Objekt zugreifen darf.

Beispiel: GET /api/v1/orders/1001 liefert die eigene Bestellung zurück. GET /api/v1/orders/1002 sollte für einen anderen Nutzer 403 Forbidden zurückgeben - gibt die API stattdessen 200 OK zurück, liegt eine BOLA-Schwachstelle vor.

Testmethodik:

1. Als User A anmelden, eigene Ressourcen-IDs notieren
2. Als User B anmelden, mit User-A-IDs auf Ressourcen zugreifen
3. Auch als nicht-authentifizierter User testen

IDs können in verschiedenen Formen vorkommen: sequenzielle Integer (/api/users/123 → 124), UUIDs oder Base64-kodierte Werte. Bei letzteren hilft Dekodierung und Neukodierung einer anderen ID.

Automatisiert mit der Autorize-Extension für Burp Suite: User-B-Cookie in den "Interception filter" eintragen, als User A browsen. Autorize wiederholt alle Requests automatisch mit User-B-Cookie und markiert identische Responses als potenzielle BOLA-Schwachstelle.

Fix im Code: Datenbankabfragen müssen immer auf den aktuellen Nutzer eingeschränkt sein:

# Schlecht - prüft nur ob Objekt existiert:
order = Order.find(params[:order_id])

# Gut - scoped auf den authentifizierten User:
order = current_user.orders.find(params[:order_id])
# → 404 wenn Bestellung nicht dem User gehört

API5: Broken Function Level Authorization (BFLA)

Viele APIs prüfen, ob ein Nutzer authentifiziert ist (AuthN), aber nicht ob er berechtigt ist, eine bestimmte Funktion aufzurufen (AuthZ). So können normale Nutzer Admin-Endpunkte aufrufen.

Testmethodik:

1. API-Dokumentation auf Admin-Endpunkte scannen (z.B. /api/v1/admin/stats, DELETE /api/v1/users/{id})
2. Alle Endpunkte mit normalem User-Token aufrufen
3. HTTP-Verb-Fuzzing: Ein GET-Endpunkt kann erlaubt sein, DELETE auf derselben URL aber nicht ausreichend gesichert

Beim Verb-Fuzzing ist die Unterscheidung der Antwortcodes wichtig: 405 Method Not Allowed bedeutet, die Methode ist nicht implementiert. 403 Forbidden bedeutet, die Methode existiert, ist aber für diesen User gesperrt. 200 OK bei einem destructiven Verb mit normalem User-Token ist eine BFLA-Schwachstelle.

Mass Assignment und Excessive Data Exposure

Mass Assignment (API3)

Backend-Frameworks, die alle Parameter eines PUT/PATCH-Requests direkt auf ein Datenbankobjekt mappen, sind anfällig für Mass Assignment. Ein Angreifer ergänzt den Request um Felder, die eigentlich schreibgeschützt sein sollten:

PATCH /api/v1/users/me
{
  "name": "Max Mustermann",
  "email": "max@example.com",
  "role": "admin"
}

Akzeptiert der Server das role-Feld, kann sich ein Nutzer selbst zum Admin hochstufen. Weitere typische Angriffsziele sind isVerified, balance oder subscription.

Test: Alle Felder aus einer GET-Response extrahieren (z.B. mit jq 'keys') und in einem PATCH-Request mit geänderten Werten zurücksenden.

Excessive Data Exposure

APIs geben häufig mehr Felder zurück, als die UI anzeigt. Die Filterung findet clientseitig statt - wer die API direkt aufruft, sieht alle Felder. Typische Datenlecks: passwordHash, internalNotes, ssn oder andere interne Flags, die in der UI ausgeblendet werden. Jedes Feld, das nicht für den Client gedacht ist, sollte serverseitig bereits aus der Response entfernt werden.

JWT-Schwachstellen

JSON Web Tokens (Header.Payload.Signature, je Base64URL-kodiert) sind weit verbreitet und weisen wiederkehrende Schwachstellen auf:

Algorithm None: Server akzeptiert JWTs mit "alg": "none" im Header und ohne Signatur - jede Payload wird als gültig behandelt.

RS256 → HS256 Downgrade: Ein mit RS256 (asymmetrisch) signiertes Token wird auf HS256 umgestellt. Der Angreifer erstellt eine HMAC-Signatur mit dem öffentlichen Schlüssel des Servers - der Server verifiziert HS256 mit demselben Schlüssel und akzeptiert das Token.

Schwacher HS256-Secret-Key: Bei kurzen oder vorhersehbaren Secrets lässt sich der Schlüssel offline per Brute-Force ermitteln (z.B. mit hashcat -m 16500 oder jwt_tool -C -d wordlist.txt).

kid-Header-Injection: Das kid-Feld im JWT-Header gibt an, welchen Schlüssel der Server verwenden soll. Eine manipulierte Angabe wie ../../dev/null kann dazu führen, dass der Server einen leeren Schlüssel verwendet.

Tests lassen sich gut mit jwt_tool durchführen, das alle gängigen JWT-Angriffe automatisiert und einen interaktiven Modus für manuelle Payload-Manipulation bietet.

GraphQL Security Testing

Introspection

GraphQL-APIs erlauben häufig auch in Produktionsumgebungen Introspection-Abfragen, die das vollständige Schema zurückgeben - inklusive aller Typen, Queries und Mutations. Mit GraphQL Voyager lässt sich das Schema visuell explorieren. Die InQL-Extension für Burp Suite automatisiert GraphQL-spezifische Tests.

Batching-Angriffe

GraphQL-Clients können mehrere Operationen in einem einzigen HTTP-Request bündeln. Rate-Limiting auf Request-Ebene wird dadurch umgangen: Statt 1.000 separater Login-Requests sendet ein Angreifer einen einzigen Batch-Request mit 1.000 Passwörtern. Schutz: Rate-Limiting auf Operationen-Ebene, nicht auf Request-Ebene.

Field-Level BOLA und Query-Tiefe

Nutzer können eigene Objekte abfragen, aber auch fremde IDs übergeben - das Standard-BOLA-Muster gilt auch für GraphQL-Felder. Zusätzlich kann eine tief verschachtelte Query (user { posts { author { posts { author { ... } } } } }) zu exponentiell wachsenden Datenbankabfragen und einem DoS führen. Abhilfe: Query-Depth-Limiting und Query-Cost-Analysis.

API Security Testbericht

Die Dokumentation von API-Schwachstellen folgt einem strukturierten Template. Am Beispiel einer BOLA-Schwachstelle enthält ein Finding: Titel, OWASP-Referenz (z.B. API1:2023), CVSS-Score mit Vektor, betroffenen Endpunkt, Beschreibung des Problems, einen Proof of Concept mit reproduzierbaren HTTP-Requests sowie eine klare Remediation-Empfehlung.

Für den Proof of Concept einer BOLA-Schwachstelle gegen GET /api/v1/orders/{orderId} sieht das so aus:

# User B greift auf User A's Bestellung zu:
curl -H "Authorization: Bearer USER_B_TOKEN" \
  https://api.example.com/api/v1/orders/10001
# Erwartet: 403 Forbidden
# Erhalten: 200 OK mit vollständigen Bestelldaten von User A

Remediation: Alle Datenbankabfragen auf den authentifizierten Nutzer scopen (current_user.orders.find_by!(id: params[:id])). Rückgabe von 404 statt 403 empfohlen, um keine Information über die Existenz fremder Ressourcen preiszugeben.

Für Reproduzierbarkeit und Nachverfolgung empfiehlt sich die Ablage aller Test-Requests als Postman-Collection. Nuclei-Templates für bekannte API-Schwachstellenmuster können den Test-Prozess ergänzen.