API Pentesting: Methodik für REST und GraphQL

Was API Pentesting von Web Pentesting unterscheidet

Ein Web-Pentest denkt in Seiten, Sessions und Nutzerflüssen. Ein API-Pentest denkt in einem Vertrag: Eine API ist ein definiertes Interface aus Ressourcen, Endpunkten und Methoden, das von anderer Software aufgerufen wird. Daraus ergeben sich die zentralen Unterschiede:

• Die API ist ein Vertrag: Endpunkte, Parameter, Typen und erwartete Antworten sind meist formal beschrieben (OpenAPI, GraphQL-Schema). Dieser Vertrag ist zugleich die beste Landkarte für den Test.
• Keine UI als Sicherheitsgrenze: Was das Frontend ausblendet, existiert auf API-Ebene weiter. Jede Autorisierung muss serverseitig je Aufruf erzwungen werden, nicht im Client.
• Maschinelle Nutzung: Clients sind Apps, Dienste und Integrationen. Requests lassen sich beliebig formen, wiederholen und variieren, ohne durch eine Oberfläche zu müssen.
• Versionen und Sichtbarkeit: APIs existieren oft in mehreren Versionen gleichzeitig, intern wie extern, teils undokumentiert.

REST und GraphQL sind dabei zwei unterschiedliche Vertragsmodelle: REST ist ressourcen- und methodenorientiert (Endpunkt plus HTTP-Methode), GraphQL exponiert ein einziges Schema, über das der Client gezielt Felder abfragt. Beide teilen dieselben Kernfragen nach Authentisierung und Autorisierung, unterscheiden sich aber deutlich in Discovery und Angriffsfläche. GraphQL bekommt deshalb einen eigenen Abschnitt.

Discovery und Dokumentation

Der erste Schritt ist, den Vertrag vollständig zu kennen. Je mehr der Tester über Endpunkte, Parameter und Versionen weiß, desto gezielter wird der Test. Die wichtigsten Quellen:

Entscheidend ist der nächste Schritt: aus dieser Dokumentation eine Testmatrix ableiten. Aus einer OpenAPI-Beschreibung entsteht eine Liste aller Endpunkte mit ihren Methoden; kombiniert mit den bekannten Rollen, Objekttypen und Mandanten ergibt sich ein systematisches Raster, welcher Aufruf unter welcher Identität getestet werden muss. Dieses Raster ist die Operator-Testmatrix weiter unten - die Doku liefert ihre Zeilen.

Ein eigener Blick gilt dem Verhältnis von API Gateway und Backend: Eine Authentisierung am Gateway bedeutet nicht automatisch, dass das Backend selbst korrekt geschützt ist. Direkter Backend-Zugriff oder eine unterschiedliche Policy-Durchsetzung zwischen Gateway und Backend kann eine eigene Testfläche sein - es geht dabei um das Vertrauensmodell, nicht um eine Umgehungsanleitung; bei cloud-gehosteten Gateways, Backends und Service-Identitäten vertieft das der Deep-Dive zu Cloud Pentesting.

Authentisierung & Token

APIs authentifizieren maschinell, meist über Token. Der Test zielt nicht auf eine Payload-Sammlung, sondern auf das Vertrauensmodell: Wem glaubt der Server auf Basis welches Tokens, und hält diese Annahme stand? Dieser Token-Inhaber ist oft ein clientseitiges Programm wie eine mobile App, dessen lokale Annahmen die API nie als Autorisierung akzeptieren darf.

Ein JWT lässt sich gefahrlos inspizieren: Der Payload ist nur base64-kodiert und zeigt, welche Claims (Rolle, Scope, Ablaufzeit, Mandant) der Server mitführt. Das ist reine Lesearbeit und der Ausgangspunkt für die Frage, welchen dieser Claims der Server ungeprüft vertraut.

Die Angriffsfläche liegt im serverseitigen Vertrauen, nicht im Token selbst. Wo Tokens erbeutet oder missbraucht werden, berührt das die Taktik Credential Access; die konkreten Techniken liegen dort und in der Payload-Sammlung.

Objekt- und Funktionsautorisierung

Das ist der Kern eines API-Pentests. Ohne UI, die Aktionen ausblendet, entscheidet allein die serverseitige Prüfung pro Aufruf, wer auf welches Objekt und welche Funktion zugreifen darf. Genau hier liegen die häufigsten und schwersten API-Fehler.

BOLA (Broken Object Level Authorization) ist der Klassiker: Die API gibt ein Objekt heraus, weil die ID stimmt, ohne zu prüfen, ob der aufrufende Token-Inhaber es besitzen darf. Der Nachweis bleibt minimal - ein fremdes Objekt genügt, Objektbesitz und Mandantentrennung werden belegt, nicht ausgeschöpft.

Grundlage dieser Tests ist eine Rollen-/Endpoint-Matrix: welche Rolle welchen Endpunkt mit welcher Methode aufrufen darf. Sie wird systematisch gegengeprüft (siehe Operator-Testmatrix). BOLA und BFLA entsprechen den bekannten Kategorien der OWASP API Security Top 10, die hier als Referenz dienen, nicht als Gliederung.

Mass Assignment & Excessive Data Exposure

Zwei gegenläufige Datenprobleme: Beim einen akzeptiert die API zu viel, beim anderen gibt sie zu viel zurück.

Mass Assignment: Der Client sendet zusätzliche Felder, die serverseitig nicht erlaubt sein dürften, und die API übernimmt sie ungeprüft in das Objekt - etwa eine Rolle oder ein Freigabe-Flag. Ursache ist meist blindes Vertrauen in das eingehende Objekt oder den Serializer.

Excessive Data Exposure: Die Antwort enthält mehr, als die Oberfläche zeigt - interne oder versteckte Felder, Daten anderer Objekte, Flags. Typische Ursache ist ein DTO oder Serializer, der das komplette Datenmodell zurückgibt und sich darauf verlässt, dass der Client nur das Vorgesehene anzeigt. Der Nachweis ist das rohe Response-Objekt mit den zu viel gelieferten Feldern.

Terminologisch verstehen neuere API-Sicherheitsmodelle beide Probleme häufig als fehlerhafte Autorisierung auf Objekt- und Property-Ebene - also als Spezialfall der Frage, wer welche Felder setzen oder sehen darf.

Input Validation & Injection

Die Injection-Grundlagen - jede Eingabe als nicht vertrauenswürdig behandeln, Senken finden, mit harmloser Probe verifizieren - sind dieselben wie bei Webanwendungen und im Web-Pentesting-Artikel ausführlich beschrieben. Hier zählen nur die API-spezifischen Unterschiede:

• Mehr Eingabequellen: Nicht nur der Body, sondern auch Header, Pfadparameter, Query-Parameter und Content-Type sind Eingaben - jede davon kann in eine Senke fließen.
• Formate und Parser: JSON, XML und multipart werden unterschiedlich geparst. Unterschiede zwischen Parsern (etwa bei doppelten Feldern oder Typ-Coercion) sind eine eigene Fehlerquelle.
• Injection-Klassen: SQL, NoSQL, LDAP und Command Injection werden hier nur als Mechanik eingeordnet - dieselbe Verifikationslogik wie im Web-Artikel, angewandt auf die jeweilige API-Eingabequelle statt auf ein Formularfeld.

Gerade NoSQL-Injection ist API-typisch, weil viele JSON-APIs direkt auf Dokumentdatenbanken sitzen: Ein strukturierter JSON-Wert kann dort als Operator statt als Literal interpretiert werden. Die Verifikation bleibt harmlos und zielt nur darauf, ob die Eingabe die Abfrage beeinflusst.

Rate Limiting & Resource Consumption

Weil APIs maschinell und wiederholbar genutzt werden, ist der Umgang mit Last eine eigene Prüfklasse - und eine, die besonders verantwortungsvoll im Scope bleiben muss. Es geht nicht darum, einen Dienst zu überlasten, sondern darum, kontrolliert nachzuweisen, dass Schutzmechanismen fehlen oder teure Operationen ungebremst möglich sind.

• Rate Limits: Existiert eine Begrenzung pro Konto, Token oder IP, und greift sie auf allen relevanten Endpunkten?
• Pagination, Filter, Sort: Lassen sich über Parameter sehr große oder sehr teure Ergebnismengen anfordern?
• Teure Queries: Einzelne Aufrufe, die serverseitig überproportional viel Arbeit auslösen.
• GraphQL-Tiefe und Komplexität: Verschachtelte oder aliasierte Abfragen, die eine einzelne Anfrage stark aufblähen (siehe GraphQL-Abschnitt).
• Batch-Requests: Mehrere Operationen in einem Aufruf, die Limits je Einzelrequest umgehen.

Die Verifikation ist bewusst kontrolliert: ein moderater, abgestimmter Test, der belegt, dass eine Grenze fehlt - kein Dauerlast- oder DoS-Lauf. Die zulässige Intensität steht in den Rules of Engagement.

GraphQL im Detail

GraphQL verdient eine eigene Betrachtung, weil es die Angriffsfläche anders schneidet als REST: ein einziger Endpunkt, ein starkes Typsystem und ein Client, der selbst bestimmt, welche Felder er anfragt.

• Introspection & Schema Enumeration: Ist die Introspection aktiv, liefert sie das vollständige Schema - alle Typen, Queries, Mutations und Felder.
• Query, Mutation, Subscription: Lesen, Schreiben und Streams werden getrennt betrachtet; jede Operationsart braucht eigene Autorisierung.
• Resolver-Level Authorization: Die entscheidende Frage ist, ob die Autorisierung pro Resolver und pro Feld greift - oder nur am Einstieg. Unterschiedliche Rechte auf einzelnen Feldern eines Typs sind eine typische Lücke.
• Aliasing & Batching: Über Aliase und Batching lassen sich viele Operationen in einer Anfrage bündeln - relevant für Autorisierung wie für Resource Consumption.
• Tiefe & Komplexität: Ohne Begrenzung von Query-Tiefe und -Komplexität wird eine einzige Abfrage zum Lastproblem.

Offene Introspection ist dabei zunächst eine Discovery-Quelle, nicht automatisch ein Befund: Ob sie sicherheitsrelevant ist, hängt von Exponierung, Umgebung, Informationsgehalt und Schutzmodell ab - dass __schema antwortet, genügt allein nicht. Der eigentliche Prüfwert liegt in der Autorisierungslogik, etwa ob einzelne Felder und Resolver unterschiedlich geschützt sind. Scharfe Abuse-Payloads gehören nicht hierher.

API-Versionierung und versteckte Angriffsfläche

Ein großer Teil realer API-Schwächen liegt nicht in der aktuellen, dokumentierten Version, sondern daneben:

• Alte und deprecated Versionen: /v1/ läuft oft weiter, mit schwächerer oder anderer Autorisierungslogik als /v2/.
• Mobile und private APIs: Für Apps gebaute Endpunkte, die weniger streng geprüft wurden als die öffentliche API.
• Unterschiedliche Gateways: Derselbe Endpunkt über verschiedene Gateways kann unterschiedlich autorisiert sein, oder das Backend ist direkt erreichbar.
• Test- und Dev-APIs: Nicht-produktive Umgebungen, die versehentlich erreichbar sind.
• Shadow APIs: Endpunkte, die niemand mehr auf dem Schirm hat und die entsprechend ungepflegt sind.

Dass eine API nach außen erreichbar ist, macht sie zur Angriffsfläche; das berührt die Taktik Initial Access (Exploit Public-Facing Application), bleibt hier aber bewusst nur eingeordnet.

Operator-Testmatrix

Die systematische Stärke eines API-Pentests liegt darin, denselben Aufruf entlang mehrerer Dimensionen zu variieren. Das ist der API-Gegenpart zur Request-Variation-Matrix aus dem Web-Artikel, um Tenant und API-Version erweitert:

Die Leitfrage ist immer dieselbe: Was passiert mit demselben Aufruf unter veränderter Identität, Methode, ID, Mandant, Parameter oder Version? Diese Matrix systematisch durchzugehen deckt den Großteil der schweren API-Fehler auf.

Automatisiert oder manuell?

Wie beim Web-Pentest teilen sich Werkzeug und Mensch die Arbeit nach Art der Schwachstelle.

Schema-getriebene Tools liefern Breite, kontrolliertes Fuzzing deckt Robustheitsfehler auf - aber Autorisierung, Mandantentrennung und Logik findet nur die manuelle Analyse mit Rollen- und Objektdenken. Jeder automatische Fund wird manuell bestätigt, bevor er in den Bericht kommt.

Nachweis & Reporting

Ein API-Befund wird über die rohen Requests und Responses belegt, die ihn zeigen, inklusive der verwendeten Rolle und Objekt-ID. Dabei gilt:

• Token redigieren: Bearer Tokens, API Keys und Secrets gehören im Bericht geschwärzt.
• Minimale fremde Daten: Bei BOLA und Tenant-Fehlern genügt ein einzelnes fremdes Objekt als Beleg - keine Massendaten.
• Reproduzierbare Sequenz: Die genaue Abfolge der Aufrufe, damit der Fund nachvollziehbar ist.
• Rollen-/Endpoint-Matrix: Als kompakter Beleg, welche Rolle welchen Endpunkt unerlaubt erreichen konnte.

Die Berichtsstruktur vertieft der Deep-Dive zu Pentest Reporting; die Risikobewertung der Deep-Dive zu Risikobewertung und CVSS. Die Erkennungsseite - welche Spuren diese Zugriffe in Logs und Telemetrie hinterlassen - vertieft das Schwesterportal blue-team.net.

Häufige Fragen

Ist API Pentesting nicht Teil des Web-Pentests?

Es überschneidet sich, folgt aber einer eigenen Methodik: schema-getrieben, token-basiert, mit Autorisierung je Objekt und Funktion und ohne UI als Grenze. Die allgemeine Pentest-Methodik - Scope, Phasen, Risikobewertung, Reporting - steht im Grundlagenartikel, die Grundlagen zum browser- und UI-zentrierten Testen im Web-Pentesting-Artikel.

Warum steht BOLA so im Fokus?

BOLA gehört zu den häufigsten und folgenreichsten API-Autorisierungsfehlern: Die API gibt ein Objekt heraus, weil die ID stimmt, ohne zu prüfen, ob der Token-Inhaber es besitzen darf. Eng verwandt sind fehlende Funktionsautorisierung und mangelnde Mandantentrennung.

Reicht ein Schema-Scanner?

Schema-getriebene Scanner können relevante technische Befunde und breite Abdeckung liefern. Autorisierung, Tenant-Isolation und Geschäftslogik benötigen jedoch typischerweise manuelle Kontextprüfung.

Wie werden GraphQL-APIs behandelt?

Mit denselben Kernfragen nach Authentisierung und Autorisierung, aber eigener Discovery (Introspection), Resolver- und Feld-Autorisierung sowie Tiefen- und Komplexitätsgrenzen - siehe den GraphQL-Abschnitt oben.