OWASP API Security Top 10 2023: Die kritischsten API-Sicherheitsrisiken

APIs sind das unsichtbare Fundament der digitalen Welt. Sie verbinden Anwendungen, ermöglichen Datenflüsse und schaffen nahtlose Nutzererlebnisse. Genau diese zentrale Rolle macht APIs allerdings auch zu einem bevorzugten Angriffsziel für Cyberkriminelle.

Das Open Web Application Security Project (OWASP) veröffentlicht regelmäßig die API Security Top 10, eine Liste der kritischsten Sicherheitsrisiken für APIs. Die Version von 2023 zeigt deutlich: API-Sicherheit ist komplexer geworden und erfordert einen systematischen Ansatz.

Warum API-Sicherheit so wichtig ist

Moderne Anwendungen verlassen sich auf Hunderte oder sogar Tausende von API-Aufrufen. Ein einziger unsicherer Endpunkt kann zum Einfallstor für Angreifer werden. Die Folgen reichen von Datenlecks über Compliance-Verstöße bis hin zu finanziellen Schäden in Millionenhöhe.

Laut dem State of API Security Report 2023 von Salt Security sind API-Angriffe in den letzten Jahren um über 400% gestiegen. Gleichzeitig zeigt sich, dass viele Organisationen ihre API-Sicherheit noch nicht ausreichend im Griff haben.

Die OWASP API Security Top 10 2023 im Überblick

Die zehn kritischsten Risiken umfassen Broken Object Level Authorization auf Platz eins, gefolgt von Broken Authentication und Broken Object Property Level Authorization. Platz vier bis sechs belegen Unrestricted Resource Consumption, Broken Function Level Authorization sowie Unrestricted Access to Sensitive Business Flows. Die hinteren Plätze gehen an Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management und schließlich Unsafe Consumption of APIs.

Die Top 10 im Detail

API1:2023 – Broken Object Level Authorization (BOLA)

BOLA bleibt das kritischste API-Sicherheitsrisiko. APIs prüfen häufig nicht ausreichend, ob ein Nutzer tatsächlich auf das angeforderte Objekt zugreifen darf. Ein typisches Beispiel: Ein Nutzer ändert in der URL /api/users/123/orders die ID auf 124 und erhält plötzlich Zugriff auf die Bestellungen eines anderen Nutzers.

Als Gegenmaßnahme sollte für jeden API-Aufruf eine Autorisierungsprüfung auf Objektebene implementiert werden. UUIDs statt sequentieller IDs erschweren das Erraten gültiger Referenzen erheblich. Wichtig ist außerdem, sich nie nur auf Client-seitige Validierung zu verlassen.

API2:2023 – Broken Authentication

Schwache Authentifizierungsmechanismen ermöglichen es Angreifern, legitime Nutzerkonten zu kompromittieren oder komplett zu umgehen. Häufige Schwachstellen sind fehlendes Rate-Limiting bei Login-Versuchen, schwache Token-Generierung oder -Validierung, Klartext-Übertragung von Credentials und fehlende Multi-Faktor-Authentifizierung.

Abhilfe schafft die Implementierung von OAuth 2.0 oder OpenID Connect in Kombination mit starken Token-Mechanismen wie JWT mit kurzer Laufzeit. Rate-Limiting und Account-Lockout sollten selbstverständlich sein.

API3:2023 – Broken Object Property Level Authorization

Diese Kategorie fasst die ehemaligen Risiken Excessive Data Exposure und Mass Assignment zusammen. APIs geben oft mehr Daten zurück als nötig oder akzeptieren ungeprüft Eingabedaten. Ein Beispiel: Eine API gibt bei einer Nutzerabfrage auch interne Felder wie isAdmin oder passwordHash zurück.

Hier hilft Response-Filterung, bei der nur tatsächlich benötigte Felder zurückgegeben werden. Input-Validierung mit expliziten Allowlists und Schema-Validierung für Request und Response runden die Absicherung ab.

API4:2023 – Unrestricted Resource Consumption

Ohne angemessene Limits können Angreifer APIs überlasten oder hohe Kosten verursachen, insbesondere bei Cloud-basierten Services. Typische Angriffsvektoren sind Denial-of-Service durch Massenanfragen, Resource Exhaustion bei rechenintensiven Operationen und Billing-Angriffe bei Pay-per-Use-Modellen.

Rate-Limiting pro Nutzer, IP und API-Key ist hier essenziell. Für Listen-Endpunkte sollte Pagination implementiert werden, und Timeouts sowie maximale Payload-Größen gehören definiert.

API5:2023 – Broken Function Level Authorization

Angreifer können administrative oder privilegierte Funktionen aufrufen, wenn die Autorisierung auf Funktionsebene fehlt. Ein Beispiel: Ein normaler Nutzer kann /api/admin/users/delete aufrufen, weil nur die Authentifizierung, nicht aber die Rolle geprüft wird.

Role-Based Access Control (RBAC) ist hier der Schlüssel. Administrative Endpunkte sollten in separaten API-Gateways isoliert werden, und grundsätzlich gilt das Deny-by-Default-Prinzip.

API6:2023 – Unrestricted Access to Sensitive Business Flows

Diese Kategorie ist neu in der 2023er Version. Angreifer missbrauchen legitime Geschäftsprozesse durch Automatisierung, etwa durch Ticket-Scalping, Credential Stuffing oder automatisierte Gutschein-Einlösung.

Bot-Detection und CAPTCHA für kritische Flows können hier Abhilfe schaffen. Verhaltensanalyse und Anomalie-Erkennung helfen, automatisierte Angriffe zu identifizieren. Business-Logic-Validierung wie etwa Kauflimits rundet die Absicherung ab.

API7:2023 – Server Side Request Forgery (SSRF)

Ebenfalls neu in 2023: SSRF-Angriffe ermöglichen es, den Server zu manipulieren, sodass er Anfragen an interne Systeme oder externe Ziele sendet.

URL-Validierung mit strikten Allowlists ist hier Pflicht. Netzwerksegmentierung für Backend-Services erschwert Angriffe zusätzlich, und ausgehende Verbindungen sollten aktiv überwacht und eingeschränkt werden.

API8:2023 – Security Misconfiguration

Fehlerhafte Konfigurationen sind ein häufiges Einfallstor. Typische Probleme sind CORS-Fehlkonfiguration, aktivierte Debug-Endpoints in Produktion, fehlende TLS-Verschlüsselung und Default-Credentials.

Automatisierte Security-Scans in der CI/CD-Pipeline helfen, solche Probleme frühzeitig zu erkennen. Infrastructure-as-Code mit Security-Baselines und regelmäßige Configuration-Audits sollten Standard sein.

API9:2023 – Improper Inventory Management

Organisationen verlieren oft den Überblick über ihre API-Landschaft. Shadow APIs und veraltete Endpunkte werden so zu Sicherheitsrisiken.

Ein gepflegtes und automatisiert aktualisiertes API-Inventar schafft Abhilfe. Ein API-Gateway als zentraler Zugangspunkt hilft bei der Übersicht, und Deprecation-Policies für alte API-Versionen sorgen dafür, dass veraltete Schnittstellen nicht zum Risiko werden.

API10:2023 – Unsafe Consumption of APIs

Ebenfalls neu in 2023: Auch die Nutzung externer APIs birgt Risiken. Blinde Vertrauensstellung gegenüber Third-Party-APIs kann zu Sicherheitslücken führen.

Externe API-Responses sollten immer validiert werden. Timeouts und Circuit-Breaker schützen vor Ausfällen, und Third-Party-APIs sollten regelmäßig auf Sicherheit bewertet werden.

Fazit: API-Sicherheit als kontinuierlicher Prozess

Die OWASP API Security Top 10 2023 zeigen: API-Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Die neuen Kategorien wie Unrestricted Access to Sensitive Business Flows und SSRF verdeutlichen, dass sich die Bedrohungslandschaft ständig weiterentwickelt.

Als nächste Schritte empfiehlt es sich, ein API-Inventar zu erstellen und zu pflegen sowie automatisierte Security-Tests in die CI/CD-Pipeline zu integrieren. Regelmäßige Penetrationstests und Schulungen für Entwickler in API-Sicherheit runden einen soliden Sicherheitsansatz ab.

Quellen und weiterführende Links

Die offizielle OWASP API Security Top 10 2023 Dokumentation findet sich unter https://owasp.org/API-Security/editions/2023/en/0x11-t10/

Der State of API Security Report 2023 von Salt Security ist verfügbar unter https://salt.security/api-security-trends

Weitere Informationen bietet das OWASP API Security Project unter https://owasp.org/www-project-api-security/ sowie das NIST Cybersecurity Framework unter https://www.nist.gov/cyberframework

Ergänzend lohnt sich ein Blick auf die CWE/SANS Top 25 Software Weaknesses unter https://cwe.mitre.org/top25/