API Penetration Testing · Moritz Samrock

API Penetration Testing ist das autorisierte Sicherheitstesten von Programmierschnittstellen – REST, GraphQL, gRPC, SOAP und WebSocket-Endpoints – mit dem Fokus auf Authentifizierungsfehler, Autorisierungsumgehungen, Injection-Schwachstellen und Business-Logic-Schwächen. Da APIs zunehmend die primäre Schnittstelle darstellen, über die Anwendungen Daten austauschen und Funktionalität bereitstellen, gehören sie zu den am schnellsten wachsenden Angriffsflächen moderner Software.

Ein API-Pentest geht über automatisiertes Scanning hinaus und testet auf Logikfehler, die Scanner nicht erkennen: Broken Access Control zwischen Objekt- und Funktionsebene, Missbrauch von Geschäftsprozessen und komplexe Autorisierungsketten mit OAuth 2.0-Flows und JWT-basiertem Session-Management.

Wer beauftragt diesen Test?

API Penetration Tests werden von Product Ownern, API-Plattform-Teams, CISOs und Partnerorganisationen beauftragt, die vor einer Integration eine Sicherheitsvalidierung verlangen. Typische Auftraggeber sind Organisationen, die öffentliche APIs launchen, API-Marktplätze betreiben oder B2B-Partner über API-Integrationen onboarden. Compliance-Anforderungen unter PCI DSS, SOC 2 und HIPAA behandeln APIs zunehmend als erstrangige Audit-Ziele.

Ziel des Tests

Ziel ist die Identifikation ausnutzbarer Schwachstellen in API-Endpoints, bevor sie von Angreifern oder böswilligen Konsumenten entdeckt und missbraucht werden. Konkrete Ziele umfassen die Validierung von Authentifizierung und Session-Management, das Testen horizontaler und vertikaler Autorisierungskontrollen, die Bewertung von Input-Validierung und Injection-Resistenz, die Evaluierung von Rate Limiting und Abuse Prevention sowie die Identifikation übermäßiger Datenexposition und Informationsleakage durch API-Responses und Fehlermeldungen.

Was wird getestet?

Getestet wird die gesamte API-Angriffsfläche: Authentifizierung – Token-Validierungsstärke, Session-Lebenszyklus, Credential-Handling, OAuth 2.0-Flow-Implementierung, JWT-Signaturprüfung (Algorithm Confusion, none-Algorithmus, Key Confusion), API-Key-Management und Multi-Faktor-Authentifizierungs-Enforcement. Autorisierung – Broken Object Level Authorization (BOLA/IDOR), Broken Function Level Authorization (BFLA), Mass Assignment, Tenant Isolation in Multi-Tenant-APIs und Privilege Escalation durch Parameter Tampering. Input-Handling – SQL Injection, NoSQL Injection, Command Injection, SSRF über API-Parameter, XML External Entity (XXE) in SOAP-APIs und Input-Validation-Bypass. GraphQL-spezifisch – Introspection in Produktion aktiviert, Depth- und Complexity-Attacks (Query Nesting, Batching), Field-Level-Authorization-Gaps und Alias-basierter Rate-Limit-Bypass. Business Logic – Workflow-Abuse, Race Conditions, Parameter Pollution und Data-Integrity-Violations. Datenexposition – verbose Fehlermeldungen, überzählige Felder in Responses, Debug-Endpoints und API-Versionierung, die veraltete (weniger abgesicherte) Endpoints exponiert.

Übliche Schwachstellen und Findings

Broken Object Level Authorization (BOLA/IDOR) ermöglicht Zugriff auf Daten anderer Benutzer durch Manipulation von Objekt-Identifiern
Broken Function Level Authorization (BFLA) erlaubt unprivilegierten Benutzern den Aufruf administrativer Endpoints
Mass Assignment ermöglicht Angreifern die Modifikation geschützter Felder durch Einfügen unerwarteter Parameter
Übermäßige Datenexposition durch API-Responses, die mehr Felder zurückgeben als der Client benötigt
Fehlendes oder unwirksames Rate Limiting ermöglicht Credential Stuffing, Enumeration und DoS
Schwache JWT-Validierung: fehlende Signaturprüfung, Akzeptanz des none-Algorithmus oder Symmetric-Key-Confusion
Fehlende Token-Expiration erlaubt unbefristete Session-Wiederverwendung
SSRF über API-Parameter, die benutzerkontrollierte URLs akzeptieren
GraphQL-Introspection in Produktion aktiviert, die das vollständige Schema exponiert
GraphQL-Depth- und Complexity-Attacks, die Ressourcenerschöpfung verursachen
Insecure Direct Object References in verschachtelten Ressourcen-Endpoints
Veraltete API-Versionen bleiben mit schwächeren Sicherheitskontrollen erreichbar
Verbose Fehlermeldungen leaken interne Pfade, Stack Traces und Datenbankdetails

Ablauf eines API Penetrationstests

Ein API Penetrationstest folgt einem strukturierten Engagement-Prozess, der auf API-spezifisches Testen zugeschnitten ist:

Interesse und Erstanfrage – der Auftraggeber nimmt Kontakt auf, häufig getrieben durch einen bevorstehenden API-Launch, Partner-Onboarding-Anforderungen oder Compliance-Vorgaben. Erstgespräch zum Verständnis der Kundenziele – der Testanbieter trifft sich mit dem API-Plattform-Team und Sicherheitsverantwortlichen, um die API-Landschaft zu verstehen: Anzahl der Endpoints, API-Stile (REST, GraphQL, gRPC), Authentifizierungsmechanismen, Deployment-Architektur und Dokumentationsstatus (OpenAPI/Swagger-Specs, GraphQL-Schemas). Angebotserstellung und Freigabe – der Anbieter erstellt ein Angebot mit Methodik (ausgerichtet an den OWASP API Security Top 10), Endpoint-Scope, Zeitplan und Kosten. Scope-Definition – beide Seiten einigen sich auf Ziel-APIs, Umgebungen (Staging bevorzugt, Produktion wenn nötig), Authentifizierungs-Credentials und Rollen für Multi-Rollen-Tests sowie Ausschlüsse (z. B. Payment-Processing-Endpoints, Rate-Limit-sensitive Produktions-APIs). Letter of Engagement – die formale Autorisierung wird unterzeichnet und deckt explizit automatisierte und manuelle Testaktivitäten gegen die vereinbarten Endpoints ab. Erstellung weiterer Freigaben – API-Zugangs-Credentials werden für mehrere Autorisierungsebenen provisioniert (unauthentifiziert, Benutzer, Admin, Partner). Wenn Third-Party-APIs in der Aufrufkette liegen, kann Benachrichtigung oder separate Autorisierung erforderlich sein. Bereitstellung von Informationen – der Auftraggeber stellt typischerweise OpenAPI/Swagger-Spezifikationen, GraphQL-Schemas, Postman-Collections oder gleichwertige Dokumentation bereit. Für Gray-Box-Tests werden Architekturdiagramme und Datenfluss-Dokumentation geteilt. Black-Box-Tests erhalten nur Endpoint-URLs und öffentlich verfügbare Dokumentation. Kick-Off Call – Testteam, API-Entwickler und Sicherheits-Stakeholder stimmen Zeitpläne, Testumgebungen, Rate-Limiting-Schwellenwerte zur Vermeidung von Störungen und den Prozess für die Meldung kritischer Findings ab. Durchführung – das Team testet systematisch über die OWASP API Security Top 10-Kategorien, ergänzt automatisiertes Tooling mit manuellen Tests auf Business-Logic- und Autorisierungsschwächen. Kritische Findings wie Datenlecks oder Authentifizierungsumgehungen werden sofort gemeldet. Sammlung und Bewertung der Schwachstellen – alle Findings werden mit vollständigen Request/Response-Nachweisen dokumentiert, nach Schweregrad bewertet und auf die OWASP API Security Top 10 sowie CWE-Referenzen gemappt. Erstellung des Abschlussberichts – ein umfassender Bericht gliedert die Findings nach API-Security-Kategorie, mit spezifischen Behebungsempfehlungen (Code-Level-Fixes, Middleware-Änderungen, Gateway-Konfigurationen) und einer priorisierten Behebungs-Roadmap. Vorstellung in einer Präsentation – die Ergebnisse werden dem API-Plattform-, Entwicklungs- und Sicherheitsteam präsentiert. Projektabschluss – Retesting-Zeitfenster für kritische und hohe Findings werden vereinbart und Empfehlungen für laufendes API-Security-Monitoring dokumentiert.

Wer sollte diesen Test wann durchführen lassen?

Jede Organisation, die APIs exponiert – ob für externe Konsumenten, mobile Anwendungen, Partnerintegrationen oder interne Microservices – sollte API Penetration Testing beauftragen. Kritische Zeitpunkte sind vor dem Launch einer öffentlichen oder partnerseitigen API, nach größeren API-Änderungen (neue Endpoints, Authentifizierungsänderungen, Versionsupgrades), beim Onboarding von API-Integrationspartnern, im Rahmen von PCI-DSS- oder SOC-2-Compliance-Programmen und nach Sicherheitsvorfällen mit API-Missbrauch. Organisationen, die GraphQL-APIs betreiben, sollten früh und regelmäßig testen, da die Abfragesprache Angriffsvektoren einführt, die traditionelles Web-Application-Testing nicht abdeckt.