Venedy
Was die OWASP API Top 10 ist
Die OWASP API Security Top 10 ist die bekannteste Liste der kritischsten Sicherheitsrisiken für APIs. Herausgegeben wird sie vom OWASP API Security Project, einem offenen Community-Projekt der OWASP Foundation (Open Worldwide Application Security Project). Die aktuelle Ausgabe von 2023 ist die zweite, vier Jahre nach der Erstausgabe von 2019.
OWASP versteht die Liste als Dokument zur Sensibilisierung. Sie zeigt, wo APIs typischerweise brechen, ersetzt aber keinen Prüfstandard. Für die Ausgabe 2023 gibt es bisher keine offizielle deutsche Übersetzung, nur für 2019. Diese Seite erklärt die aktuelle Ausgabe deshalb auf Deutsch und verlinkt jedes Risiko auf die englische Originalquelle.
Die zehn Risiken im Überblick
Drei der zehn Einträge sind reine Autorisierungsfehler: API1 (BOLA), API3 (BOPLA) und API5 (BFLA). Sie prüfen jeweils eine andere Ebene: Gehört dem Nutzer dieses Objekt? Darf er dieses Feld ändern? Darf er diese Funktion aufrufen?
Broken Object Level Authorization
Zugriff auf fremde Objekte über manipulierte IDs (BOLA). Das häufigste und folgenreichste API-Risiko.
Broken Authentication
Schwächen bei Login, Token oder Sitzungen, die eine fremde Identität ermöglichen.
Broken Object Property Level Authorization
Zugriff auf oder Änderung einzelner Objekt-Eigenschaften jenseits der eigenen Rechte (BOPLA).
Unrestricted Resource Consumption
Fehlende Limits führen zu Überlast oder hohen Kosten, etwa durch teure Abfragen ohne Drosselung.
Broken Function Level Authorization
Aufruf von Funktionen, die der eigenen Rolle nicht zustehen, etwa Admin-Aktionen als normaler Nutzer (BFLA).
Unrestricted Access to Sensitive Business Flows
Automatisierter Missbrauch sensibler Abläufe, etwa Massen-Buchungen oder Käufe.
Server Side Request Forgery
Die API wird verleitet, Anfragen an interne Systeme zu stellen (SSRF).
Security Misconfiguration
Unsichere Standardeinstellungen, offene Debug-Endpunkte oder fehlende Härtung.
Improper Inventory Management
Veraltete, undokumentierte oder vergessene Endpunkte, Schatten- und Orphan-APIs.
Unsafe Consumption of APIs
Blindes Vertrauen in Daten von Drittanbieter-APIs, ohne eigene Prüfung.
Die zehn Risiken im Detail
API1:2023 Broken Object Level Authorization (BOLA)
Die API prüft, ob ein Nutzer angemeldet ist, aber nicht, ob er genau das angefragte Objekt sehen oder ändern darf. Angreifer tauschen die Objekt-ID in der Anfrage aus und erhalten fremde Daten.
Beispiel: Ein Shop-Betreiber ruft seine Umsatzdaten über GET /shops/{shopName}/revenue_data.json ab und setzt der Reihe nach die Namen anderer Shops ein.
API2:2023 Broken Authentication
Schwächen beim Login, bei Tokens oder Sitzungen erlauben es, sich als jemand anderes auszugeben. Login- und Reset-Endpunkte sind für jeden erreichbar und deshalb ein bevorzugtes Ziel.
Beispiel: Ein Limit von drei Login-Versuchen pro Minute wird umgangen, indem viele Versuche in einer einzigen GraphQL-Anfrage gebündelt werden.
API3:2023 Broken Object Property Level Authorization (BOPLA)
Die API prüft den Zugriff auf das Objekt, aber nicht auf seine einzelnen Felder. Angreifer lesen Felder, die sie nicht sehen dürften, oder ändern Felder, die tabu sein sollten. BOPLA fasst die früheren Risiken „Excessive Data Exposure“ und „Mass Assignment“ zusammen.
Beispiel: Ein Nutzer ändert die Beschreibung seines gesperrten Videos und schickt ein internes Feld mit, das die Sperre aufhebt.
API4:2023 Unrestricted Resource Consumption
Es fehlen Grenzen für CPU, Speicher, Bandbreite oder kostenpflichtige Drittanbieter-Dienste. Schon einfache, massenhaft wiederholte Anfragen verursachen Ausfälle oder hohe Kosten.
Beispiel: Jeder Klick auf „Passwort vergessen“ löst eine kostenpflichtige SMS aus. Ohne Limit verschickt ein Skript Zehntausende davon.
API5:2023 Broken Function Level Authorization (BFLA)
Die API prüft nicht, ob die Rolle des Nutzers eine Funktion überhaupt ausführen darf. Normale Nutzer rufen so Admin-Funktionen auf, oft nur über eine andere HTTP-Methode oder einen erratenen Pfad.
Beispiel: Statt GET /api/invites/{id} schickt ein Angreifer POST /api/invites/new und lädt sich selbst als Admin ein.
API6:2023 Unrestricted Access to Sensitive Business Flows
Jeder einzelne Aufruf ist korrekt und erlaubt, aber der Ablauf als Ganzes lässt sich automatisiert missbrauchen, etwa bei Käufen, Buchungen oder Kommentaren.
Beispiel: Ein Bot kauft beim Verkaufsstart einer limitierten Spielkonsole den gesamten Bestand und verkauft ihn teurer weiter.
API7:2023 Server Side Request Forgery (SSRF)
Die API ruft eine vom Nutzer angegebene URL ab, ohne sie ausreichend zu prüfen. So stellt der Server Anfragen an interne Systeme, die von außen nicht erreichbar sind.
Beispiel: Ein Webhook wird auf die interne Metadaten-Adresse eines Cloud-Servers gesetzt und gibt dessen Zugangsdaten preis.
API8:2023 Security Misconfiguration
Fehlende Härtung, unsichere Standardeinstellungen, fehlende Patches oder falsch gesetzte TLS-, CORS- und Header-Konfigurationen, auf jeder Ebene des API-Stacks.
Beispiel: Eine Logging-Bibliothek wertet Platzhalter standardmäßig aus, und ein präparierter Header genügt, um Code auf dem Server auszuführen.
Mehr zu Security Misconfiguration
API9:2023 Improper Inventory Management
Organisationen verlieren den Überblick über ihre APIs. Alte Versionen, vergessene Beta- oder Test-Hosts und undokumentierte Endpunkte laufen weiter, oft ohne die Schutzmaßnahmen der Produktion.
Beispiel: Ein Beta-Host ohne vorgeschaltetes Rate-Limiting erlaubt Brute Force auf die Passwort-Zurücksetzung.
API10:2023 Unsafe Consumption of APIs
Die API vertraut Daten von Drittanbieter-APIs mehr als Nutzereingaben und prüft sie weniger streng. Angreifer greifen deshalb den integrierten Dienst an statt die API selbst.
Beispiel: Ein kompromittierter Speicherdienst antwortet mit einer Weiterleitung, die die API ungeprüft befolgt, und sensible Daten landen beim Angreifer.
Was sich gegenüber 2019 geändert hat
Die Ausgabe 2023 übernimmt die Grundstruktur von 2019, setzt aber neue Schwerpunkte:
- Zusammengelegt: „Excessive Data Exposure“ (2019: API3) und „Mass Assignment“ (2019: API6) bilden jetzt gemeinsam API3 BOPLA. Beide haben dieselbe Ursache, die fehlende Prüfung auf Feldebene.
- Neu: API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery und API10 Unsafe Consumption of APIs.
- Geschärft und umbenannt: „Lack of Resources & Rate Limiting“ heißt jetzt API4 Unrestricted Resource Consumption, mit dem Fokus auf dem Verbrauch selbst statt nur auf der Drosselung. „Broken User Authentication“ heißt jetzt API2 Broken Authentication, „Improper Assets Management“ heißt API9 Improper Inventory Management.
- Nicht mehr in der Liste: „Injection“ und „Insufficient Logging & Monitoring“. Beide bleiben wichtig, siehe Injection und Logging & Monitoring.
- Unverändert an der Spitze: BOLA bleibt API1.
Welche Risiken Scanner finden und welche nicht
Die zehn Risiken unterscheiden sich stark darin, wie man sie findet:
- Oft automatisch erkennbar: viele Fälle von Security Misconfiguration (API8), fehlende Limits (API4) und bekannte Schwächen der Authentifizierung (API2). Sie zeigen sich an der Konfiguration oder am Verhalten einzelner Anfragen.
- Nur mit Kontext prüfbar: BOLA, BOPLA und BFLA (API1, API3, API5) sowie Business Flows (API6). Ob ein Befund vorliegt, hängt davon ab, wem ein Objekt gehört, welche Rolle ein Nutzer hat und welcher Ablauf erlaubt ist. Dafür braucht es mehrere Test-Identitäten und Wissen über die Geschäftslogik.
- Nur mit Überblick prüfbar: Improper Inventory Management (API9) setzt voraus, dass man alle laufenden APIs kennt, auch die vergessenen.
Genau bei der zweiten und dritten Gruppe setzt Venedy an: mit der Discovery des echten API-Bestands und mit Angriffen über mehrere Identitäten, jeweils mit Beleg je Befund. So arbeitet Venedy · Vergleich BOLA, BFLA, BOPLA
Häufige Fragen
Gibt es die OWASP API Top 10 auf Deutsch?
Offiziell nur die Ausgabe 2019. Für die aktuelle Ausgabe 2023 bietet OWASP bisher Übersetzungen ins Französische, Persische, Indonesische und Portugiesische an, aber keine deutsche. Diese Seite erklärt die Ausgabe 2023 auf Deutsch und verlinkt jeweils den Originaltext.
Wie entsteht die Liste?
Für 2023 hat OWASP erstmals öffentlich um Daten gebeten, es wurden aber keine beigesteuert. Die Liste beruht deshalb auf der Erfahrung des Projektteams, dem Review durch API-Security-Fachleute und dem Feedback der Community auf einen Release Candidate.
Wie oft wird sie aktualisiert?
Es gibt keinen festen Rhythmus. Die erste Ausgabe erschien 2019, die zweite vier Jahre später.
Was ist der Unterschied zur OWASP Top 10 für Webanwendungen?
Die bekannte OWASP Top 10 deckt Webanwendungen allgemein ab. Die API Security Top 10 konzentriert sich auf Risiken, die bei APIs besonders häufig sind, vor allem Berechtigungsfehler auf Objekt-, Feld- und Funktionsebene. OWASP betont, dass sie die anderen Top-10-Listen nicht ersetzt.
Quellen
- OWASP API Security Top 10 (Übersicht, 2023) OWASP API Security Project, 2023
- Release Notes: Änderungen gegenüber 2019 OWASP API Security Project, 2023
- OWASP API Security Top 10 2019, deutsche Übersetzung (PDF) OWASP API Security Project, 2019
- OWASP API Security: verfügbare Übersetzungen der Ausgabe 2023 OWASP API Security Project, GitHub