Checkliste

API-Pentest: die Checkliste für SaaS- und Software-Teams

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Ein API-Pentest prüft, ob Ihre Schnittstelle nur das herausgibt und nur das ausführt, was dem jeweiligen Konto erlaubt ist. Im Mittelpunkt stehen die Risiken der OWASP API Security Top 10, aktuell in der Fassung 2023: vor allem fehlende Autorisierung auf Objekt-, Eigenschafts- und Funktionsebene, aber auch fehlende Limits, Server-Side Request Forgery und der unkritische Umgang mit fremden APIs. Der wichtigste Prüfschritt lässt sich in einem Satz sagen: Mit zwei Konten aus zwei Mandanten wird jede Objekt-ID des einen gegen das Token des anderen getauscht, und keine einzige Anfrage darf durchgehen.

Warum APIs das Hauptziel sind

In einer SaaS-Anwendung ist die Oberfläche nur ein Client unter mehreren. Web-Frontend, Mobile-App und Integrationen sprechen mit derselben API, und was die Oberfläche ausblendet, kann die API trotzdem liefern. Ein Angreifer sieht in den Entwicklerwerkzeugen des Browsers die Anfragen samt IDs und Token und schickt sie verändert erneut ab. Eine bekannte Lücke in einer Bibliothek braucht er dafür nicht.

Genau deshalb sind die typischen API-Schwachstellen keine exotischen Programmierfehler, sondern Lücken in der Geschäftslogik:

• Autorisierung auf Objektebene (BOLA). Die API prüft, ob jemand angemeldet ist, aber nicht, ob ihm das angefragte Objekt gehört. OWASP führt das als Risiko Nummer eins.
• Autorisierung auf Funktionsebene. Ein normales Konto erreicht Verwaltungsfunktionen, weil die Prüfung nur im Frontend steckt oder eine andere HTTP-Methode nicht abgesichert ist.
• Mass Assignment. Die API übernimmt Felder aus der Anfrage ungefiltert in das Datenobjekt, auch Felder wie Rolle oder Mandanten-Zuordnung.
• Server-Side Request Forgery (SSRF). Die API ruft eine vom Nutzer angegebene URL ab, etwa für Webhooks oder Link-Vorschauen, und lässt sich so auf interne Dienste lenken.
• Fehlende Limits. Ohne Begrenzung von Anfragen, Seitengrößen oder kostenpflichtigen Folgeaktionen wie SMS-Versand werden Missbrauch und Kosten zum Risiko.
• Unsichere Nutzung fremder APIs. Daten von Zahlungsdienstleistern, CRMs oder KI-Diensten gelten intern oft als vertrauenswürdig und werden schwächer geprüft als Nutzereingaben.

Für SaaS-Anbieter wiegt der erste Punkt am schwersten. Wenn ein Kunde über die API Daten eines anderen Kunden lesen kann, ist das Vertrauensversprechen der ganzen Plattform gebrochen.

Die OWASP API Security Top 10 (Fassung 2023)

Das Open Worldwide Application Security Project (OWASP) veröffentlicht neben der bekannten Top 10 für Webanwendungen eine eigene Liste für APIs. Die erste Ausgabe erschien 2019, die aktuelle zweite Ausgabe 2023. Eine neuere Fassung ist auf der Projektseite (Stand 28.10.2026) nicht veröffentlicht. Laut den Release Notes wurden für die Fassung 2023 keine Daten eingereicht. Die Liste beruht auf der Erfahrung des Projektteams, der Prüfung durch API-Sicherheitsfachleute und Rückmeldungen der Community. Sie ist damit eine Sensibilisierungsliste und kein Prüfstandard mit Bestehensgrenze.

Gegenüber 2019 hat OWASP „Excessive Data Exposure“ und „Mass Assignment“ zu API3 zusammengefasst, weil beide dieselbe Ursache haben: fehlende Autorisierung auf Ebene einzelner Eigenschaften. API6 und API10 sind 2023 neu hinzugekommen.

Wie ein API-Pentest abläuft

Den allgemeinen Ablauf eines Penetrationstests, von der Freigabe bis zum Nachtest, beschreiben wir in einem eigenen Artikel: Penetrationstest: Ablauf, Dauer und was ihn kostet. Hier geht es um das, was bei APIs anders ist. Drei Dinge entscheiden darüber, wie aussagekräftig der Test wird.

Scope: Spezifikation und Inventar

Grundlage ist eine aktuelle Beschreibung der Schnittstelle, meist als OpenAPI-Spezifikation (früher Swagger), bei GraphQL das Schema. Sie zeigt alle Endpunkte, Parameter und erwarteten Antworten und macht den Test planbar. Genauso wichtig ist die Frage, was nicht in der Spezifikation steht. OWASP nennt unter API9 ausdrücklich alte Versionen, vergessene Hosts und fehlende Dokumentation als Risiko. Legen Sie deshalb schriftlich fest:

• welche Hosts und Versionen geprüft werden, etwa api.example.com/v2, und ob /v1 noch erreichbar ist,
• welche Endpunkte ausgenommen sind und warum, zum Beispiel Zahlungsauslösung oder Massenversand,
• welche angebundenen Fremddienste berührt werden dürfen und welche nicht,
• wer im Ernstfall während des Tests erreichbar ist.

Rollen und Testkonten je Mandant

Ein API-Pentest ohne passende Testkonten bleibt an der Oberfläche. Für eine mandantenfähige Anwendung braucht es mindestens zwei getrennte Mandanten, in jedem Mandanten ein Konto je relevanter Rolle und in jedem Konto echte Testdaten, also angelegte Objekte wie Projekte, Rechnungen oder Dokumente. Erst dann lässt sich prüfen, ob Mandant A an die Objekte von Mandant B kommt und ob eine einfache Rolle Funktionen einer höheren erreicht.

Umgebung

Am besten eignet sich eine Staging-Umgebung, die in Code, Konfiguration und vorgeschalteten Komponenten wie API-Gateway und Web Application Firewall der Produktion entspricht. Weicht sie ab, prüft der Test ein anderes System. OWASP rät unter API9, in Nicht-Produktivumgebungen keine Produktionsdaten zu verwenden und sie andernfalls genauso zu schützen wie die Produktion. Zahlungsdienstleister, E-Mail- und SMS-Versand sollten im Testmodus laufen, damit Tests zu API4 und API6 keine echten Kosten oder Nachrichten auslösen.

Wichtig für alle, die selbst testen: Prüfen Sie nur Systeme, für die eine schriftliche Freigabe des Betreibers vorliegt. Das gilt auch für angebundene Fremd-APIs, die Ihnen nicht gehören.

Die Prüfschritte im Einzelnen

Die folgenden Schritte orientieren sich an der OWASP API Security Top 10 und am Kapitel „API Testing“ des OWASP Web Security Testing Guide. Die Beispielpfade sind erfunden und stehen für Muster, die in vielen APIs vorkommen.

1. Objektzugriff: IDs zwischen Mandanten tauschen (API1)

Der wichtigste Einzeltest. Mit Konto A wird ein Objekt angelegt, etwa eine Rechnung. Dann wird dieselbe Anfrage mit dem Token von Konto B geschickt:

GET /api/v2/invoices/8f3c… mit Authorization: Bearer <Token von B-User>

• Erwartet: 403 oder 404. Eine Antwort 200 mit den Daten von A ist ein Befund.
• Alle Methoden prüfen. Nicht nur lesen, auch PUT, PATCH und DELETE auf fremde Objekte. Ein Endpunkt, der beim Lesen prüft, aber beim Löschen nicht, ist nicht selten.
• IDs an jeder Stelle. IDs stecken im Pfad, in Query-Parametern, im JSON-Body, in Headern und in GraphQL-Abfragen. Jede Stelle wird einzeln getauscht.
• Listen und Filter. Endpunkte wie GET /api/v2/invoices?customer_id=… oder Exporte liefern oft ganze Datensätze. Prüfen, ob der Filter auf den eigenen Mandanten beschränkt bleibt.
• Zufällige IDs sind kein Schutz. UUIDs erschweren das Raten, aber IDs tauchen in Links, E-Mails, Logs und anderen Antworten auf. OWASP empfiehlt sie als Ergänzung, nicht als Ersatz für die Prüfung je Objekt.

2. Eigenschaften und Mass Assignment (API3)

• Antworten lesen. Enthält GET /api/v2/users/me Felder, die der Nutzer nicht sehen sollte, etwa interne Kennzeichen, Hashes oder Daten anderer Personen? Das Frontend blendet sie vielleicht aus, die API liefert sie trotzdem.
• Felder hinzufügen. Eine Aktualisierung wie PATCH /api/v2/users/me um Felder wie "role": "admin", "tenant_id": "…" oder "plan": "enterprise" ergänzen. Übernimmt die API sie, ist das Mass Assignment.

3. Funktionsebene: Rollen und Methoden (API5)

• Verwaltungsfunktionen mit einfachem Konto aufrufen. Endpunkte, die nur Administratoren nutzen, mit dem Token von A-User ansprechen, etwa Benutzer einladen, Rollen ändern oder alle Daten exportieren.
• Methode wechseln. Wenn GET /api/v2/users/42 erlaubt ist, was passiert bei DELETE auf denselben Pfad?
• Nicht auf den Pfad verlassen. OWASP weist darauf hin, dass Verwaltungsfunktionen oft nicht unter /admin liegen, sondern zwischen normalen Endpunkten.
• Ohne Anmeldung. Jeden Endpunkt einmal ganz ohne Token aufrufen.

4. Anmeldung und Token (API2)

• Wird die Signatur von Token geprüft? Akzeptiert die API ein JWT mit "alg": "none" oder ein abgelaufenes Token?
• Sind Anmeldung, Passwort-Reset und Einmalcodes gegen massenhaftes Durchprobieren geschützt?
• Stehen Token oder Passwörter in URLs, wo sie in Logs landen?
• Verlangen sensible Änderungen wie E-Mail-Adresse oder Passwort eine erneute Bestätigung?

5. Limits und sensible Abläufe (API4, API6)

• Seitengröße. Akzeptiert ?limit= beliebig große Werte? Eine einzige Anfrage kann dann ganze Tabellen abfragen und die Datenbank belasten.
• Wiederholte Aktionen. Wie oft lässt sich ein Einmalcode prüfen, ein Passwort-Reset anfordern oder eine Einladung verschicken?
• Kostenpflichtige Folgeaktionen. Lösen Anfragen SMS, E-Mails oder Aufrufe bezahlter Dienste aus? OWASP empfiehlt Ausgabenlimits beim Anbieter oder zumindest Abrechnungswarnungen.
• Geschäftsabläufe. Lässt sich ein Ablauf automatisiert ausnutzen, etwa alle Termine reservieren oder Testzugänge massenhaft anlegen? Hier geht es nicht um einen Programmierfehler, sondern um fehlende Begrenzung.

6. Server-Side Request Forgery (API7)

Überall, wo die API eine vom Nutzer angegebene URL abruft, etwa Webhook-Ziele, Import per Link, Bild von URL oder Link-Vorschau:

• Interne Ziele angeben: localhost, private Adressbereiche und die Metadaten-Dienste der Cloud-Umgebung.
• Weiterleitungen testen: eine erlaubte externe URL, die auf ein internes Ziel weiterleitet. OWASP empfiehlt, Weiterleitungen beim Abruf abzuschalten.
• Andere Schemata und Ports prüfen und ob die rohe Antwort des Ziels an den Nutzer zurückgegeben wird.

7. Konfiguration und Inventar (API8, API9)

• Fehlermeldungen ohne Stacktraces und interne Pfade, TLS durchgängig, CORS nur für die eigenen Ursprünge.
• Ältere Versionen wie /v1 abgeschaltet oder genauso geschützt wie die aktuelle.
• Staging-, Test- und Debug-Endpunkte nicht öffentlich erreichbar.

8. Fremde APIs (API10)

• Daten aus angebundenen Diensten werden geprüft wie Nutzereingaben, bevor sie in Datenbank, Vorlagen oder Folgesysteme gehen.
• Verbindungen nur verschlüsselt, Weiterleitungen nicht blind folgen, Zeitlimits und Größenbegrenzungen für Antworten gesetzt.
• Webhooks von Drittanbietern werden auf ihre Signatur geprüft, bevor die API sie verarbeitet.

Die Checkliste zum Abhaken

Was automatisierte Scanner finden und was nicht

API-Scanner und Fuzzer sind nützlich, und ein guter Test setzt sie ein. Sie arbeiten die Spezifikation ab, schicken veränderte Eingaben und vergleichen Antworten mit bekannten Mustern. Das deckt eine bestimmte Klasse von Fehlern zuverlässig ab. Die Autorisierungslogik gehört nicht dazu.

Der Grund ist einfach: Eine Antwort 200 mit Daten sieht für einen Scanner korrekt aus. Ob diese Daten dem anfragenden Konto zustehen, steht nirgends in der Antwort, sondern in den Geschäftsregeln Ihrer Anwendung. Diese Regeln kennt nur, wer weiß, welches Konto welchem Mandanten gehört, und wer die Anfrage mit zwei Konten gegenprüft. OWASP beschreibt für die Funktionsebene genau das: Fehler findet man am besten durch eine gründliche Analyse des Autorisierungsmechanismus mit Blick auf Rollen und Gruppen. Wie sich eine automatische Schwachstellenanalyse insgesamt vom Penetrationstest abgrenzt, erklärt unser Artikel Schwachstellenanalyse: was sie ist und wann Sie eine brauchen.

Für Ihr Entwicklungsteam heißt das auch: Die Tauschprüfung aus Schritt 1 lässt sich als automatisierter Test in die eigene Pipeline übernehmen. OWASP empfiehlt, Tests für den Autorisierungsmechanismus zu schreiben und Änderungen nicht auszuliefern, wenn sie fehlschlagen. Der Pentest findet die Lücken, der Regressionstest verhindert, dass sie zurückkommen.

Was im Ergebnisbericht stehen sollte

Ein API-Pentest-Bericht ist dann brauchbar, wenn Ihr Entwicklungsteam jeden Befund ohne Rückfrage nachstellen kann. Je Befund gehören dazu:

• Betroffener Endpunkt und Methode, mit Version und Host.
• Die konkrete Anfrage und Antwort als Nachweis, mit Angabe, welches Testkonto welchen Mandanten verwendet wurde.
• Auswirkung in Ihren Worten, etwa „Mandant B kann Rechnungen von Mandant A lesen und löschen“, nicht nur eine Kategorie.
• Einstufung der Schwere nach einem nachvollziehbaren Verfahren wie CVSS, mit Begründung.
• Zuordnung zur OWASP-Kategorie, damit sich Befunde mit Fragebögen und internen Richtlinien abgleichen lassen.
• Konkrete Korrektur, möglichst an der Stelle im Code oder in der Konfiguration, wo sie hingehört.

Dazu kommen eine Management-Zusammenfassung, die Abdeckung (welche Endpunkte und Rollen geprüft wurden, welche nicht) und ein Nachtest der Korrekturen.

API-Pentest oder SaaS-Pentest?

Bei vielen SaaS-Produkten ist die API der größte Teil der Angriffsfläche, aber nicht der einzige. Mandantentrennung betrifft auch Datei-Ablagen, Hintergrundjobs, Suchindizes, Exporte und den Support-Zugang. Wenn Ihr Ziel der Nachweis für einen Enterprise-Kunden ist, dass kein Mandant in die Daten eines anderen sieht, ist ein SaaS-Penetrationstest mit Fokus auf Mandantentrennung der passende Rahmen, und die API-Prüfung ist sein Kern. Geht es um eine öffentliche oder Partner-API ohne eigene Oberfläche, reicht oft der API-Pentest allein.

Häufige Fragen

Weiterlesen

• OWASP Top 10 2025 erklärt
• Lovable-Sicherheit: So machen Sie Ihre Lovable-App sicher
• Penetrationstest: Ablauf, Dauer und was ihn kostet
• Schwachstellenanalyse: was sie ist und wann Sie eine brauchen
• MCP und OAuth: den Vertrauensanker absichern
• Leistung: SaaS-Penetrationstest mit Fokus auf Mandantentrennung

Quellen

• OWASP API Security Top 10 2023: Übersicht der zehn Risiken
• OWASP API Security Top 10 2023: Release Notes
• OWASP API1:2023 Broken Object Level Authorization
• OWASP API5:2023 Broken Function Level Authorization
• OWASP API7:2023 Server Side Request Forgery
• OWASP Web Security Testing Guide: API Broken Object Level Authorization
• OWASP Web Security Testing Guide: API Broken Function Level Authorization
• OWASP API Security Project auf GitHub (Fassungen 2019 und 2023)