Penetrationstest vorbereiten: 12 unverzichtbare Tipps
20/10/2026
Netzwerksegmentierung testen: Die ultimative Checkliste
25/10/2026API-Pentest: Die ultimative Checkliste für Unternehmen
Ein API-Pentest prüft, ob Schnittstellen Daten und Funktionen ausschließlich den berechtigten Personen und Systemen bereitstellen. Dabei stehen nicht nur technische Schwachstellen im Mittelpunkt: Besonders relevant sind fehlerhafte Objektberechtigungen, unzureichende Mandantentrennung und manipulierbare Geschäftsprozesse. Für Unternehmen mit Kundenportalen, mobilen Apps oder SaaS-Plattformen kann ein gezielter Schnittstellentest deshalb deutlich mehr aussagen als ein automatisierter Schwachstellenscan.
Warum ein API-Pentest für Unternehmen wichtig ist
Eine API (Application Programming Interface) verbindet Anwendungen miteinander. Sie ermöglicht etwa, dass eine mobile App Bestellungen abruft, ein Kundenportal Rechnungen anzeigt oder ein externer Partner Daten mit einem ERP-System austauscht. Häufig läuft der Zugriff unsichtbar im Hintergrund. Die Schnittstelle ist trotzdem ein eigenständiger Angriffspunkt.
Ein sicheres Login im Frontend garantiert nicht, dass das Backend jede Anfrage korrekt autorisiert. Wer eine Anfrage technisch verändern kann, versucht möglicherweise, fremde Datensätze abzurufen oder Funktionen zu nutzen, die für seine Rolle nicht vorgesehen sind. Genau solche Szenarien gehören zum API-Pentest als spezialisierter Sicherheitsprüfung.
Die OWASP API Security Top 10 (Ausgabe 2023) beschreiben zentrale Risikokategorien. Sie sind eine wertvolle Orientierung, ersetzen aber keine anwendungsspezifische Analyse von Rollen, Datenflüssen und Geschäftslogik.
Sieben kritische Risiken, die ein API-Pentest aufdecken soll
1. Fehlende Objektberechtigungen (BOLA/IDOR)
Ein Benutzer ruft über eine API seine Rechnung ab. Die Anfrage enthält beispielsweise eine Rechnungs-ID. Wenn das Backend nur prüft, ob jemand angemeldet ist, aber nicht, ob genau diese Rechnung zum Benutzer gehört, kann eine manipulierte ID den Zugriff auf fremde Dokumente ermöglichen. Das ist ein typisches Beispiel für Broken Object Level Authorization (BOLA), häufig auch als IDOR bezeichnet.
Prüffrage: Werden Zugriffsrechte bei jedem relevanten Objekt serverseitig geprüft – auch beim Download, Export und in verschachtelten Endpunkten?
2. Fehlerhafte Rollen- und Funktionsberechtigungen
Eine normale Benutzerrolle sollte keine administrativen Funktionen aufrufen können. Trotzdem können Funktionen wie Benutzerverwaltung, Freigaben oder Preisänderungen über die API erreichbar sein, selbst wenn die Benutzeroberfläche entsprechende Schaltflächen ausblendet. Das Verstecken einer Funktion ist keine Autorisierung.
Prüffrage: Verhindert das Backend zuverlässig, dass Benutzer API-Funktionen außerhalb ihrer Rolle ausführen?
3. Manipulierbare Datenfelder und Mass Assignment
Viele APIs akzeptieren strukturierte JSON-Objekte. Werden zusätzliche Felder ungeprüft übernommen, kann ein Benutzer unter Umständen Eigenschaften verändern, die nicht zu seinem Berechtigungsumfang gehören – etwa interne Freigabestatus, Kontozuordnungen oder Rollenattribute. Ebenso kritisch ist es, wenn API-Antworten mehr personenbezogene oder geschäftliche Daten enthalten als benötigt.
Prüffrage: Sind erlaubte Eingabefelder und ausgegebene Daten pro Rolle und Geschäftsprozess eindeutig begrenzt?
4. Schwächen bei Anmeldung, Tokens und Sitzungen
APIs verwenden häufig OAuth 2.0, OpenID Connect, JSON Web Tokens oder API-Schlüssel. Entscheidend ist nicht das verwendete Verfahren allein, sondern seine korrekte Umsetzung: Werden Signaturen, Ablaufzeiten, Aussteller und Zielgruppe von Tokens geprüft? Können abgemeldete oder gesperrte Benutzer weiterhin auf sensible Funktionen zugreifen? Werden langlebige Zugangsdaten ausreichend geschützt?
Prüffrage: Bleiben Authentifizierung und Sitzungsverwaltung auch bei manipulierten, abgelaufenen oder falsch eingesetzten Zugangsdaten wirksam?
5. Fehlende Begrenzung von Anfragen und Geschäftsprozessen
Unbegrenzte API-Aufrufe können Systeme überlasten oder kostenpflichtige Hintergrundprozesse auslösen. Noch wichtiger: Eine technisch gültige Funktion kann missbraucht werden, wenn sich beispielsweise Reservierungen, Gutscheine oder Registrierungen massenhaft automatisieren lassen. Ein bloßes Rate Limit pro IP-Adresse reicht für solche Fälle nicht immer aus.
Prüffrage: Sind ressourcenintensive Endpunkte und sensible Geschäftsabläufe gegen missbräuchliche Automatisierung geschützt?
6. Vergessene API-Versionen und Schatten-Schnittstellen
Während neue Endpunkte abgesichert werden, bleiben ältere Versionen, Testsysteme oder Debug-Funktionen gelegentlich erreichbar. Eine veraltete API kann andere Sicherheitsregeln verwenden als die aktuelle Anwendung. Deshalb gehört eine Bestandsaufnahme aller freigegebenen Schnittstellen und Versionen zum sinnvollen Prüfumfang.
Prüffrage: Gibt es ein vollständiges API-Inventar und einen geregelten Prozess, um nicht mehr benötigte Endpunkte abzuschalten?
7. Unsichere Integrationen und serverseitige Requests
APIs rufen ihrerseits externe Dienste auf, etwa zur Dokumentenverarbeitung, Zahlungsabwicklung oder Datenanreicherung. Wenn Zieladressen oder Rückgabedaten unzureichend validiert werden, können Angriffswege wie Server-Side Request Forgery (SSRF) oder unsichere Verarbeitung von Drittanbieterantworten entstehen. Auch fehlerhafte CORS- und Transportkonfigurationen verdienen eine Prüfung.
Prüffrage: Werden externe Ziele, Antworten und Vertrauensgrenzen unabhängig vom aufrufenden Client kontrolliert?
Wie läuft ein professioneller API-Pentest ab?
Ein API-Pentest beginnt mit der Festlegung der Angriffsziele und des erlaubten Testumfangs. Relevante Informationen sind API-Basisadressen, OpenAPI- oder Swagger-Spezifikationen, GraphQL-Schemas, Rollenmodelle, Testkonten und bekannte Integrationen. Eine vorhandene Dokumentation beschleunigt die Prüfung, ist aber keine Voraussetzung für jede Testart.
Danach werden Endpunkte und Datenflüsse analysiert. Der Pentester prüft zunächst, welche Funktionen erreichbar sind und wie Authentifizierung und Autorisierung umgesetzt wurden. Anschließend werden ausgewählte Anfragen kontrolliert verändert: zum Beispiel Objektkennungen, Rollen, JSON-Eigenschaften, Methoden und Parameter. Bei GraphQL kommen unter anderem Query-Komplexität und Berechtigungen auf Feld- und Resolver-Ebene hinzu.
Die Ergebnisse werden manuell verifiziert und im geschäftlichen Zusammenhang bewertet. Ein unerlaubter Zugriff auf einen einzelnen Testdatensatz ist anders zu beurteilen als ein reproduzierbarer Zugriff über Mandantengrenzen hinweg. Die Prüfung muss so geplant sein, dass produktive Daten nicht unnötig verändert oder ausgelesen werden.
Im Bericht sollten betroffene Endpunkte, Voraussetzungen, nachvollziehbare Nachweisschritte, Auswirkungen und konkrete Abhilfemaßnahmen stehen. Ein optionaler Retest kontrolliert anschließend die Behebung der dokumentierten Schwachstellen.
API-Pentest vorbereiten: Diese Angaben helfen beim Scoping
- Schnittstellen: Basis-URLs, Versionen, REST- oder GraphQL-Endpunkte und bekannte externe Integrationen.
- Rollen: Mindestens zwei normale Testkonten sowie – sofern relevant – unterschiedliche Berechtigungsstufen.
- Mandanten: Getrennte Testmandanten, um die Isolation von Kundendaten kontrolliert zu prüfen.
- Dokumentation: OpenAPI-Spezifikation, Beispielanfragen und eine Beschreibung sensibler Geschäftsprozesse.
- Testregeln: Freigaben, Ausschlüsse, Lastgrenzen, Umgang mit Schreiboperationen und Notfallkontakte.
- Ergebnisziel: Gewünschte Prüftiefe, Berichtsformat und gegebenenfalls ein Retest.
Gerade bei mandantenfähigen SaaS-Anwendungen sind zwei voneinander unabhängige Testmandanten besonders wertvoll. Nur damit lassen sich viele Fragen zur Trennung von Kundendaten praxisnah beantworten. Bei produktiven Systemen werden risikoreiche Aktionen vorab abgestimmt oder in einer geeigneten Testumgebung nachgestellt.
API-Pentest oder automatisierter API-Scan?
Automatisierte Scanner helfen dabei, technische Auffälligkeiten und bekannte Fehlkonfigurationen zu finden. Sie kennen jedoch meist nicht die fachlichen Regeln Ihrer Anwendung. Ob ein Sachbearbeiter Rechnungen einer anderen Niederlassung sehen darf oder ob eine Freigabe zwei unabhängige Personen benötigt, lässt sich nicht allein aus HTTP-Statuscodes ableiten.
Ein manueller Pentest prüft deshalb zusätzlich Rollenwechsel, Mandantentrennung und die Kombination mehrerer Funktionen. Automatisierung bleibt ein wichtiges Werkzeug, ersetzt aber nicht die Interpretation der Geschäftslogik.
Wann lohnt sich ein API-Pentest besonders?
Ein API-Pentest ist insbesondere vor dem Produktivstart eines Kundenportals, nach größeren Änderungen am Rollenmodell, bei neuen Partneranbindungen oder nach einer Cloud-Migration sinnvoll. Auch regelmäßige Prüfungen geschäftskritischer Schnittstellen können helfen, Risiken aus neuen Funktionen und gewachsenen Berechtigungen zu erkennen.
Die Kosten hängen von Anzahl und Komplexität der Endpunkte, Rollen, Mandanten, Authentifizierungsverfahren und der gewünschten Prüftiefe ab. Eine einfache CRUD-API ist anders zu bewerten als eine umfangreiche SaaS-Plattform mit komplexen Freigabeprozessen. Weitere Faktoren erläutert yatesh unter Penetrationstest-Kosten.
Fazit: Nicht nur Endpunkte, sondern Geschäftsrisiken prüfen
Ein wirksamer API-Pentest beantwortet eine zentrale Frage: Kann jemand über eine Schnittstelle Daten sehen, verändern oder Funktionen ausführen, obwohl er dazu nicht berechtigt ist? Wer Objektberechtigungen, Rollen, Mandantentrennung und Geschäftslogik gezielt prüfen lässt, erhält eine wesentlich aussagekräftigere Risikobewertung als durch einen reinen Scan.
Sie möchten die Sicherheit Ihrer REST- oder GraphQL-Schnittstellen überprüfen? yatesh unterstützt Unternehmen bei der Definition eines passenden Scopes und bei technisch nachvollziehbaren Penetrationstests. Sprechen Sie mit yatesh über Ihren API-Pentest.
