API-Penetrationstests: wo Ihre API mehr preisgibt, als sie sollte

Eine API hat keine Benutzeroberfläche, daher werden Autorisierungsfehler leicht übersehen, und zugleich fließen die sensibelsten Daten über APIs. Wir testen REST, GraphQL und gRPC nach den OWASP API Security Top 10, wo das größte Risiko Broken Object Level Authorization ist, also die Möglichkeit, durch Tausch einer Kennung an fremde Objekte zu gelangen.

Anders als bei einer Webanwendung schränken uns keine Bildschirme und Schaltflächen ein. Wir arbeiten direkt an den Endpoints und prüfen jeden auf Berechtigungen, Eingabevalidierung und übermäßige Datenpreisgabe. Ein Scanner sieht hier wenig, weil er den Kontext nicht kennt, also wer worauf Zugriff haben sollte.

Die zwei häufigsten und gefährlichsten Klassen von API-Fehlern sind die Autorisierung auf Objekt- und auf Funktionsebene. Die erste erlaubt das Lesen oder Ändern einer Ressource eines anderen Nutzers, die zweite das Auslösen einer Operation, die einer höheren Rolle vorbehalten ist. Beide sind von außen unsichtbar und erfordern Tests aus der Perspektive verschiedener Konten.

Deshalb vereinbaren wir mit Ihnen die Rollen und Testkonten und prüfen dann systematisch jede Berechtigungsgrenze. Wir bestätigen nicht nur, dass ein Endpoint existiert, sondern dass er eine Anfrage, zu der das Konto kein Recht hat, korrekt ablehnt.

Eine OpenAPI-Spezifikation oder eine fertige Anfragesammlung erhöht die Abdeckung in derselben Zeit erheblich, weil wir nicht raten müssen, welche Endpoints und Parameter existieren. Je vollständiger das Bild der API-Oberfläche, desto mehr reale Angriffspfade können wir verifizieren, statt blind zu suchen.

Wenn es keine Dokumentation gibt, führen wir den Test trotzdem durch und bilden die API aus dem Anwendungsverkehr und der Verhaltensanalyse ab. Es lohnt sich aber zu wissen, dass gute Dokumentation nicht nur eine Erleichterung für uns ist, sondern direkt mehr Wert des Tests für Sie.

Der Bericht beschreibt jede Schwachstelle mit Nachweis, CVSS-Bewertung und einer konkreten Anfrage, die das Problem reproduziert, damit das Entwicklungsteam sie sofort verifizieren kann. Wir fügen eine Management-Zusammenfassung mit der realen geschäftlichen Auswirkung und nach Risiko geordnete Behebungsprioritäten hinzu.

Nach der Behebung führen wir einen Retest durch und bestätigen, dass die Lücken geschlossen sind. Das ist besonders für eine API wichtig, die oft zwischen einer mobilen App und dem Backend steht, denn ein einziger Autorisierungsfehler kann die Daten aller Nutzer auf einmal offenlegen.

Wir testen eine API, bevor sie Partnern oder einer Client-Anwendung zugänglich gemacht wird, und nach jeder Vertragsänderung: neuen Endpoints, einer Änderung des Berechtigungsmodells oder einer Migration auf eine neue Version. Jede solche Änderung kann Zugriff öffnen, den es vorher nicht gab.

Für eine öffentlich exponierte API oder eine, die personenbezogene Daten und Zahlungen verarbeitet, empfehlen wir einen regelmäßigen Testzyklus. Zunehmend ist das auch Teil regulatorischer Anforderungen und eine Bedingung für die Zusammenarbeit mit größeren Integratoren.