Wie ein Series-B-Fintech 23 kritische API-Schwachstellen vor der nächsten Finanzierungsrunde schloss

Repräsentatives Projekt. Kundendetails anonymisiert und Einzelheiten unter NDA geändert.

Eine Zahl in einer URL ändern und die Banktransaktionen eines Fremden lesen. Das war das Erste, was wir fanden, am zweiten Tag, auf einer Fintech-API, die echtes Geld bewegt. Der Fehler blieb das ganze Jahr über offen, in dem ein “sauberer” Schwachstellen-Scan in ihrem Nachweisordner gelegen hatte.

Der Kunde war ein Series-B-Fintech, rund 40 Entwickler, sechs Wochen vor dem Start einer Series-C-Runde. Ihr Lead-Investor wollte vor der Unterzeichnung des Term Sheets eine Sicherheitsprüfung durch Dritte. Ihr Produkt war fast vollständig eine API: eine mobile App und ein Partner-Web-Dashboard, die mit demselben Satz von REST-Endpunkten sprachen. Sie baten also um API-Penetrationstests, nicht um einen Netzwerkscan und nicht um einen Bericht zum Abhaken.

Dieser Unterschied ist die ganze Geschichte. Die Probleme, die wir fanden, waren genau die Art, an der automatisierte Tools direkt vorbeilaufen. Am Ende hatten wir 23 kritische und hohe Befunde gemeldet, und die große Mehrheit davon waren Autorisierungsfehler. Die API vertraute dem Aufrufer weit mehr, als sie sollte.

Die wichtigsten Erkenntnisse

• Die schädlichsten Fintech-API-Schwachstellen sind Autorisierungsfehler (BOLA/IDOR und fehlende Autorisierung auf Funktionsebene), nicht Injection oder Fehlkonfiguration. Scanner übersehen fast alle davon.
• In diesem repräsentativen Projekt meldeten wir in sechs Wochen 23 kritische und hohe Befunde, darunter kontoübergreifende Datenpreisgabe, einen Mass-Assignment-Pfad zu einer Admin-Rolle und OTP-Endpunkte ohne Rate-Limiting.
• API-Penetrationstests bedeuten, mit mehreren echten Benutzerrollen zu testen, zu vergleichen, worauf jedes Token zugreifen darf, und die Geschäftslogik zu missbrauchen. Es geht nicht darum, eine Liste von Anfragen auf einen einzigen Endpunkt abzufeuern.
• Die Autorisierung auf Objektebene zu beheben (gehört diese Ressource diesem Benutzer?) schloss die meisten kritischen Befunde. Der Nachtest bestätigte, dass die Fixes hielten.
• Das Unternehmen bestand die technische Due Diligence, ohne dass ein Sicherheitsbefund die Finanzierungsrunde blockierte.

Der Kontext: eine API, die Geld bewegte und jedem vertraute

Der Stack war vertraut. Eine Node-und-Express-API hinter einem Gateway, PostgreSQL, JWT-Access-Tokens, ein mobiler Client und ein Partner-Dashboard. Rund 180 dokumentierte Endpunkte, plus eine Handvoll, die überhaupt nicht in der Dokumentation standen. Die gibt es immer. Nutzer konnten Guthaben halten, Überweisungen senden, Teammitglieder einladen und externe Bankkonten verknüpfen.

Ihre eigene Einschätzung des Produkts war, dass es “ziemlich solide” sei. Sie hatten eine WAF. Sie ließen einen Dependency-Scanner in der CI laufen. Ein früherer Anbieter hatte ihnen im Jahr zuvor einen sauber aussehenden Schwachstellen-Scan übergeben.

Dieser Scan ist ein gutes Beispiel dafür, warum ein Scan kein Pentest ist. Er bestätigte, dass ihre TLS-Konfiguration und die Bibliotheksversionen in Ordnung waren. Er sagte nichts darüber aus, ob Nutzer A die Transaktionen von Nutzer B lesen konnte, und genau darum ging es am Ende.

Unser Ansatz: Rollen, Tokens und worauf jedes zugreifen darf

Wir legten es als Gray-Box-Test an. Sie gaben uns die API-Dokumentation, eine Postman-Collection und mehrere Testkonten über alle Rollen hinweg: zwei Standardnutzer in getrennten Organisationen, einen Org-Admin, einen Analysten mit Nur-Lese-Rechten und ein Partner-Dashboard-Konto. Mehrere Konten pro Rolle sind die mit Abstand wichtigste Voraussetzung für echtes Autorisierungstesting. Man kann nicht beweisen, dass ein Nutzer an Daten gelangt, an die er nicht sollte, ohne die Daten eines zweiten Nutzers, nach denen man greifen kann.

Das Arbeits-Setup war unspektakulär. Burp Suite als Proxy für den mobilen Traffic und das Dashboard, wobei die Session jedes Kontos gespeichert wurde, sodass wir jede Anfrage als beliebige Identität wiederholen konnten. Ein paar Burp-Erweiterungen, um Antworten über Rollen hinweg zu vergleichen. ffuf für die Endpunkt- und Parametersuche. Dann viel manuelles Bearbeiten von Anfragen. Die meisten echten Befunde stammten aus dem sorgfältigen Lesen der Antworten, nicht aus dem Tooling.

Der erste Durchgang kartiert nur die Oberfläche: jeden Endpunkt, jeden Parameter, jedes ID-Format und welche Rolle darauf zugreifen soll. Der zweite Durchgang ist der interessante. Wir nehmen eine Anfrage, die legitim zu Nutzer A gehört, wiederholen sie mit dem Token von Nutzer B, dann mit dem Analysten-Token, dann ganz ohne Token, und beobachten, was zurückkommt.

Wie “die API testen” hier konkret aussah

Nehmen wir den Transaktions-Endpunkt. Er akzeptierte eine numerische Konto-ID im Pfad:

GET /v2/accounts/48213/transactions HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-A-token>

Ändert man 48213 zu 48214, behält das Token von Nutzer A bei, und die API lieferte die vollständige Transaktionshistorie eines anderen Kunden. Das ist Broken Object Level Authorization, in den OWASP API Security Top 10 als API1 gelistet, und dasselbe zugrunde liegende Problem, das man IDOR nennt (CWE-639). Die IDs waren fortlaufende Ganzzahlen, sodass das Durchlaufen des gesamten Kundenstamms trivial war. Erster kritischer Befund eingereicht, am zweiten Tag.

Es war kein Einzelfall. Dieselbe fehlende Eigentümerprüfung tauchte bei Kontoauszügen auf, beim Endpunkt, der die maskierten Details eines verknüpften Bankkontos zurückgab, und bei einem Rechnungs-PDF-Download, der eine Dokument-ID entgegennahm und überhaupt keine Prüfung durchführte. Eine Fehlerklasse, mehrere Endpunkte. Die Codebasis authentifizierte das Token, fragte aber nie, ob der Eigentümer des Tokens das angeforderte Objekt tatsächlich besaß.

Was wir fanden: die wichtigsten Punkte

Über die Fehler auf Objektebene hinaus sind ein paar Befunde erwähnenswert, weil sie bei Fintech-APIs immer wieder auftauchen.

Mass Assignment auf eine Admin-Rolle. Der Endpunkt zum Aktualisieren des eigenen Profils akzeptierte einen JSON-Body und band ihn direkt an das Benutzermodell. Dokumentiert waren name und email. Er akzeptierte stillschweigend auch role. Die Anfrage unten beförderte einen Standardnutzer zum Org-Admin:

PATCH /v2/users/me HTTP/1.1
Authorization: Bearer <standard-user-token>
Content-Type: application/json

{"name":"Jordan","role":"admin"}

Das ist Mass Assignment (CWE-915), der Fehler, den die aktuellen OWASP API Security Top 10 unter Broken Object Property Level Authorization einordnen. In Kombination mit dem nächsten Befund wird es richtig gefährlich.

Fehlende Autorisierung auf Funktionsebene. Die Admin-Endpunkte, die alle Org-Nutzer auflisteten und Mitgliederberechtigungen änderten, prüften, ob man authentifiziert war, aber nicht, ob man Admin war. Ein Standardnutzer konnte sie direkt aufrufen. Kombiniert man das mit dem Mass-Assignment-Fehler, hatte ein einziges Konto mit niedrigen Rechten einen glatten Weg zur vollständigen Kontrolle über eine Organisation.

OTP- und Passwort-Reset-Endpunkte ohne Rate-Limiting. Der Endpunkt zur Verifizierung des Einmalcodes akzeptierte unbegrenzte Versuche. Ein sechsstelliger Code ohne Sperre und ohne Drosselung ist kein zweiter Faktor. Er ist eine Bremsschwelle. Wir erzwangen einen gültigen Code per Brute-Force in Minuten von einer einzigen IP aus. Der Passwort-Reset-Flow hatte dieselbe Lücke.

Ein JWT, dem zu sehr vertraut wurde. Das Access-Token trug die Rolle des Nutzers und die Org-ID als Claims, und mindestens ein Dienst traf Entscheidungen anhand dieser Claims, ohne sie serverseitig erneut zu prüfen. Die Tokens hatten eine lange Lebensdauer, und es gab keine serverseitige Widerrufsmöglichkeit, sodass ein geleaktes Token viel zu lange nutzbar blieb.

Nichts davon erforderte exotisches Tooling. Es brauchte ein zweites Konto und jemanden, der bereit war zu fragen: Was passiert, wenn ich diese Anfrage als die falsche Person sende?

Das Ergebnis

Wir lieferten die Befunde laufend, statt am Ende alles auf einmal abzuladen. So handhaben wir jedes zeitlich begrenzte Projekt. Die BOLA-Probleme gingen am zweiten Tag an ihr Team, damit die Entwickler mit dem Beheben beginnen konnten, während wir weiter testeten. Jeder Befund kam mit der exakten Anfrage zum Reproduzieren, der Auswirkung in klarer Sprache und einem konkreten Fix.

Ihr Team handelte schnell. Die Fixes waren größtenteils struktureller Art: eine Middleware zur Eigentümerprüfung, die verifizierte, dass der authentifizierte Nutzer das Objekt im Pfad tatsächlich besaß, echte Rollenprüfungen auf jeder privilegierten Route, eine Allow-List für beschreibbare Felder statt des Bindens des gesamten Bodys sowie Rate-Limiting und Sperren auf den Auth-Endpunkten. Kürzere Token-Lebensdauern und eine Widerrufsliste lösten das JWT-Problem.

Wir führten einen vollständigen Nachtest gegen die Fixes durch. Alle 23 kritischen und hohen Befunde waren geschlossen und verifiziert, und die neue Eigentümer-Middleware hatte zudem zwei Befunde geringerer Schwere abgefangen, die wir markiert hatten. Als die technische Due Diligence des Investors ein paar Wochen später stattfand, blockierte nichts Sicherheitsrelevantes die Runde. Genau darum ging es: es zu finden, bevor jemand Feindseliges oder der Prüfer eines Käufers es für Sie findet.

Wie CyberXplore hilft

Das ist der Kern dessen, was unser Service für API-Penetrationstests leistet: manuelles, rollenbewusstes Testen der Endpunkte, die Ihr Geschäft tatsächlich am Laufen halten, abgebildet auf die OWASP API Security Top 10, mit Reproduktionsschritten, mit denen ein Entwickler etwas anfangen kann, und einem Nachtest, der bestätigt, dass die Fixes halten. Wenn Sie auf eine Finanzierungsrunde, eine Partnerintegration oder eine Compliance-Frist zusteuern und Ihr Produkt eine API ist, zahlt sich genau das aus. Fordern Sie ein Angebot an und erzählen Sie uns von Ihrem Stack und Zeitplan.

FAQ

Warum kann ein Schwachstellen-Scanner diese API-Fehler nicht finden?

Scanner sind gut bei bekannten Problemen: veraltete Bibliotheken, schwaches TLS, fehlende Header, einige Injection-Muster. Autorisierungsfehler wie BOLA hängen vom Geschäftskontext ab. Ein Scanner hat keine Ahnung, dass Konto 48214 zu einem anderen Kunden gehört, also sieht eine 200-Antwort für ihn in Ordnung aus. Diese zu finden erfordert einen Menschen, der vergleicht, worauf verschiedene echte Nutzer zugreifen dürfen, und das ist der Kern von API-Penetrationstests.

Wie lange dauert ein API-Penetrationstest?

Das hängt von der Anzahl der Endpunkte, der Anzahl der Rollen und dem Umfang der beteiligten Geschäftslogik ab. Ein fokussierter API-Test bei einem mittelgroßen Fintech dauert typischerweise ein bis drei Wochen aktives Testen plus einen Nachtest. Das Projekt in diesem Beitrag umfasste etwa zwei Wochen Testen innerhalb eines sechswöchigen Zeitfensters, das die Behebung und den Nachtest einschloss.

Was ist BOLA und warum ist es das größte API-Risiko?

BOLA (Broken Object Level Authorization) liegt vor, wenn eine API prüft, ob Sie angemeldet sind, aber nicht, ob das konkrete Objekt, das Sie angefragt haben, Ihnen gehört. Es steht in den OWASP API Security Top 10 an erster Stelle, weil es weit verbreitet ist, sich durch das Ändern einer ID in einer Anfrage trivial ausnutzen lässt und oft die Daten aller Nutzer auf einmal preisgibt. Es ist dasselbe Kernproblem wie IDOR (CWE-639).

Benötigen Sie Produktionszugang oder Quellcode?

Keins von beidem ist zwingend erforderlich, aber beides hilft. Die meisten unserer Projekte sind Gray-Box: Wir arbeiten gegen eine Staging- oder produktionsähnliche Umgebung mit mehreren Testkonten über alle Rollen hinweg und Zugriff auf die API-Dokumentation. Quellcode kann die Ursachenanalyse beschleunigen, aber die kritischen Befunde in diesem Fall stammten aus Gray-Box-Request-Tests, nicht aus dem Code-Review.

Was erhalten wir am Ende?

Ein Bericht, der mit dem Risiko beginnt, jeden Befund mit Schweregrad, exakten Reproduktionsschritten und einem konkreten Fix auflistet, plus ein Nachtest, der bestätigt, was tatsächlich geschlossen wurde. Wir liefern kritische Befunde, sobald wir sie finden, damit Ihr Team mit der Behebung beginnen kann, bevor das Projekt endet, und wir stehen bereit, um die Fixes mit Ihren Entwicklern durchzusprechen.

Wir stehen vor einer Finanzierungsrunde. Lohnt sich ein Pentest gerade jetzt?

Ja, und es ist oft der beste Zeitpunkt. Investoren führen zunehmend eine technische Due Diligence durch, und wenn der Prüfer eines Käufers in der Term-Sheet-Phase einen kritischen Autorisierungsfehler findet, ist das ein weit unangenehmeres Gespräch, als ihn vorab in aller Ruhe zu beheben. Ein sauberer, verifizierter Nachtestbericht ist ein starkes Signal, dass das Team Sicherheit ernst nimmt.