OWASP API Security Top 10 erklärt: So sehen die Risiken aus

APIs sind dort, wo die Daten liegen, und in den meisten unserer Web- und Backend-Pentests sind die wichtigen Findings API-Findings. Die OWASP API Security Top 10 benennen die zehn Risikoklassen, die dafür verantwortlich sind. Die aktuelle Ausgabe stammt von 2023. Unser Gründer hat auf der code.talks und bei der GDG Hannover über API-Sicherheit gesprochen, und die Beobachtung ist jedes Mal dieselbe: Die meisten API-Einbrüche sind keine cleveren Exploits, sondern eine fehlende Autorisierungsprüfung.

So sieht jedes der zehn Risiken in der Praxis aus, so testen wir darauf, und das hilft dagegen.

Die Liste im Überblick

ID	Name	In einem Satz
API1	Broken Object Level Authorization	Du kannst fremde Objekte lesen oder ändern, indem du eine ID austauschst.
API2	Broken Authentication	Tokens, Passwörter oder Sessions lassen sich erraten, stehlen oder fälschen.
API3	Broken Object Property Level Authorization	Du kannst Felder lesen oder schreiben, die du nicht sehen oder setzen dürftest.
API4	Unrestricted Resource Consumption	Niemand begrenzt, wie oft oder wie viel du anfragen darfst.
API5	Broken Function Level Authorization	Ein normaler Nutzer kann Admin-Funktionen aufrufen.
API6	Unrestricted Access to Sensitive Business Flows	Ein legitimer Ablauf lässt sich automatisieren und so missbrauchen.
API7	Server Side Request Forgery	Die API ruft eine URL ab, die du kontrollierst.
API8	Security Misconfiguration	Defaults, Debug-Endpunkte, offenes CORS, ausführliche Fehler.
API9	Improper Inventory Management	Alte Versionen und vergessene Endpunkte sind noch online.
API10	Unsafe Consumption of APIs	Deine API vertraut anderen APIs mehr als den Nutzern.

API1, API3 und API5: die drei Autorisierungsrisiken

Autorisierung ist das größte Problem in APIs, und OWASP teilt es in drei Punkte auf, weil jeder an einer anderen Stelle übersehen wird.

API1, Broken Object Level Authorization (BOLA, auch IDOR). Der Endpunkt GET /api/orders/18422 prüft, dass du eingeloggt bist, aber nicht, dass Bestellung 18422 dir gehört. Im Pentest legen wir zwei Accounts an und spielen jede Anfrage von Nutzer A mit dem Token von Nutzer B nach. In der Mehrzahl der APIs, die wir testen, fällt mindestens ein Endpunkt bei diesem Test durch. Die Lösung ist eine Prüfung gegen den Eigentümer des Objekts bei jedem Datenzugriff, am besten an einer zentralen Stelle, und nie im Client.

API3, Broken Object Property Level Authorization. Das Objekt gehört dir, aber die API liefert Felder, die du nicht sehen solltest (die E-Mail-Adresse eines anderen Nutzers im Autor-Objekt eines Kommentars), oder akzeptiert Felder, die du nicht setzen dürftest ("role": "admin" in einem Profil-Update, oft Mass Assignment genannt). Die Lösung sind explizite Request- und Response-Schemas pro Endpunkt statt der Serialisierung des Datenbankmodells.

API5, Broken Function Level Authorization. GET /api/users ist geschützt, GET /api/admin/users nicht, oder die App zeigt den Button nie an, der Endpunkt ist aber offen. Wir sammeln Endpunkte aus Dokumentation, JavaScript-Bundles und Mobile Apps und rufen jeden mit dem Account mit den geringsten Rechten auf. Die Lösung ist Deny-by-Default im Routing und eine Rollenprüfung in jeder Funktion.

API2: Broken Authentication

Die häufigen Fälle sind nicht exotisch: kein Rate Limit auf Login oder Passwort-Reset-Codes, JWTs mit alg: none oder einem schwachen HMAC-Secret, Tokens ohne Ablauf, API-Keys in Mobile Apps und Refresh-Tokens, die eine Passwortänderung überleben. RFC 8725 und RFC 9700 beschreiben den aktuellen Stand für JWT und OAuth 2.0; die meisten unserer Findings sind Abweichungen davon. Abhilfe: kurzlebige Access-Tokens, rotierende Refresh-Tokens, PKCE für öffentliche Clients, serverseitige Prüfung von Algorithmus und Audience sowie eine Sperr- oder Drosselungsregel, die getestet ist.

API4 und API6: Ressourcen und Geschäftsabläufe

Bei API4 geht es um Grenzen: ein Export-Endpunkt, der ?limit=1000000 akzeptiert, ein Bild-Endpunkt, der alles skaliert, was du hochlädst, eine SMS-Verifizierung, die dich pro Aufruf Geld kostet. Jeder dieser Fälle ist ein Kosten- oder Verfügbarkeitsproblem. Limits pro Client, pro Endpunkt und pro Ressourcentyp gehören ins Design, und ein Quota-Fehler sollte eine normale Antwort sein.

API6 ist neu in der Liste und schwerer zu automatisieren: Technisch ist nichts kaputt, aber ein Ablauf lässt sich in großem Stil missbrauchen. Alle Tickets eines Vorverkaufs kaufen, einen ganzen Katalog über die Suche abgreifen, tausende Accounts für Empfehlungsboni anlegen. Die Lösung ist zuerst eine Geschäftsentscheidung (welche Abläufe sind sensibel) und dann Geräte-Fingerprinting, Step-up-Verifizierung oder menschliche Prüfung nur für diese Abläufe.

API7: Server Side Request Forgery

Jeder Parameter, der eine URL annimmt, ist ein Kandidat: Webhooks, Avatar-Import, Link-Vorschauen, PDF-Erzeugung aus HTML. In Cloud-Umgebungen ist das erste Ziel der Metadatendienst unter 169.254.169.254, der Zugangsdaten herausgibt. Die Lösung: eine Allowlist für Ziele, Auflösung des Hostnamens vor der Anfrage mit Prüfung gegen private Adressbereiche und Metadatendienste, die ein Session-Token verlangen (IMDSv2 bei AWS).

API8: Security Misconfiguration

Ausführliche Stacktraces, Access-Control-Allow-Origin: * zusammen mit Credentials, GraphQL-Introspection und Debug-Endpunkte in Produktion, fehlendes TLS auf einem internen Hop, veraltete Frameworks. Einzeln nicht spektakulär, aber zusammen geben sie dem Angreifer die Landkarte und oft den ersten Zugang.

API9: Improper Inventory Management

/api/v1/ funktioniert noch, obwohl die App /api/v3/ nutzt, die Staging-API ist mit Produktionsdaten erreichbar, eine Partneranbindung von 2021 hat eigene, undokumentierte Endpunkte. Wir finden das mit Wortlisten, Certificate-Transparency-Logs und alten App-Versionen. Die Lösung ist ein gepflegtes API-Inventar, ein Abschaltprozess für Versionen und dieselben Kontrollen in jeder Umgebung mit echten Daten.

API10: Unsafe Consumption of APIs

Dein Backend ruft einen Zahlungsdienstleister, einen Geocoding-Dienst oder eine Partner-API auf und vertraut der Antwort: Es folgt Redirects, parst XML mit aktivierten externen Entitäten, schreibt zurückgelieferte Strings in SQL. Behandle Antworten Dritter wie Nutzereingaben: Schema prüfen, Größe begrenzen, Timeouts setzen und Redirects nicht blind folgen.

So testen wir die zehn

Ein API-Pentest bei Zyberum ist Grey Box: Wir bitten um das OpenAPI- oder GraphQL-Schema, zwei Accounts pro Rolle und eine Testumgebung mit realistischen Daten. Die Arbeit ist dann überwiegend manuell, unterstützt durch eigenes Tooling für den Autorisierungsvergleich mit zwei Accounts und durch einen Scanner für API4 und API8. Jedes Finding im Bericht ist auf die ID der API Security Top 10 abgebildet, mit CVSS bewertet und kommt mit einem Request-Response-Paar, das du nachspielen kannst.

Womit du anfängst, wenn du APIs baust

• Lege Objekt- und Funktionsautorisierung an eine Stelle und schreib Tests dafür mit zwei Nutzern.
• Definiere Request- und Response-Schemas pro Endpunkt und weise unbekannte Felder ab.
• Setze überall Limits und mach den Quota-Fehler zum Teil des API-Vertrags.
• Führe ein Inventar. Lösche, was nicht drinsteht.
• Lass die API testen, bevor ein großer Kunde dich darum bittet.

Für einen Test mit klarem Umfang siehe Web- und API-Pentest, oder frag uns in einem kostenlosen 15-Minuten-Gespräch.