Sie haben OAuth 2.0 implementiert. Sie verwenden überall HTTPS. Ihre APIs erfordern Authentifizierung. Sie denken, Sie sind sicher. Sind Sie wahrscheinlich nicht.
Die OWASP API Security Top 10 existiert, weil traditionelles Web-Sicherheitsdenken nicht vollständig auf APIs anwendbar ist. Hier sind die Schwachstellen, die die meisten Teams übersehen.
1. Broken Object-Level Authorization (BOLA)
Die häufigste API-Schwachstelle. Ihre API authentifiziert Benutzer, autorisiert aber den Zugriff auf bestimmte Objekte nicht ordnungsgemäß.
Der Angriff ist einfach: Ändern Sie /api/users/123/orders zu /api/users/124/orders. Prüft die API, ob der authentifizierte Benutzer auf die Bestellungen von Benutzer 124 zugreifen kann? Die meisten tun es nicht.
So beheben Sie es:
- Prüfen Sie die Autorisierung für jeden Objektzugriff, nicht nur die Authentifizierung
- Verwenden Sie indirekte Referenzen (GUIDs) anstelle von sequentiellen IDs
- Implementieren Sie Autorisierung auf der Datenschicht, nicht nur auf der API-Schicht
2. Übermäßige Datenexposition
APIs geben oft ganze Objekte zurück und verlassen sich darauf, dass das Frontend sensible Felder filtert. Angreifer nutzen nicht Ihr Frontend.
Ihr User-Endpoint könnte zurückgeben:
{"id": 123, "email": "user@example.com", "password_hash": "...", "ssn": "..."}So beheben Sie es:
- Geben Sie nur die Felder zurück, die der Client benötigt
- Erstellen Sie verschiedene Response-Schemas für verschiedene Kontexte
- Vertrauen Sie niemals dem Frontend, Datenfilterung zu handhaben
3. Fehlende Rate Limits
Ohne Rate Limits können Angreifer Credentials brute-forcen, Benutzer enumerieren oder einfach Ihre Infrastruktur überfordern.
So beheben Sie es:
- Implementieren Sie Rate Limiting pro Benutzer, IP und Endpoint
- Verwenden Sie progressive Verzögerungen bei wiederholten Fehlern
- Wenden Sie strengere Limits auf sensible Endpoints an (Login, Passwort-Reset)
4. Broken Function-Level Authorization
Unterscheidet sich von BOLA—hier geht es um den Zugriff auf Admin-Funktionen, nicht Admin-Daten. Kann ein normaler Benutzer /api/admin/delete-user aufrufen?
So beheben Sie es:
- Definieren Sie klare Rollen und Berechtigungen
- Prüfen Sie die Autorisierung auf jedem Endpoint, nicht nur auf Router-Ebene
- Trennen Sie Admin-APIs von User-APIs, idealerweise auf unterschiedlicher Infrastruktur
5. Mass Assignment
APIs, die JSON akzeptieren, binden es oft direkt an Objekte. Senden Sie unerwartete Felder, und sie könnten hängen bleiben:
{"name": "John", "email": "john@example.com", "is_admin": true}So beheben Sie es:
- Definieren Sie explizit, welche Felder beschreibbar sind
- Verwenden Sie DTOs/Schemas, die nur erwartete Felder enthalten
- Binden Sie Request-Daten niemals direkt an Datenbankmodelle
6. Sicherheitsfehlkonfiguration
Ausführliche Fehlermeldungen, Debug-Endpoints in Produktion, permissive CORS-Policies, fehlende Security-Header—die Basics, die vergessen werden.
API-Sicherheit ist kein Feature, das Sie hinzufügen—es ist eine Denkweise, die Sie auf jede Codezeile anwenden.
Testen Sie Ihre APIs
Automatisiertes Scanning fängt nur oberflächliche Probleme. Für echte API-Sicherheit:
- Testen Sie Autorisierung mit verschiedenen Benutzerkontexten
- Versuchen Sie Parameter-Manipulation manuell
- Überprüfen Sie, welche Daten jeder Endpoint zurückgibt
- Prüfen Sie Rate Limiting unter realistischen Angriffsszenarien
- Engagieren Sie Penetrationstester, die auf APIs spezialisiert sind
Der kulturelle Wandel
Sicherheit kann kein Nachgedanke oder die Verantwortung eines separaten Teams sein. Jeder Entwickler, der APIs baut, muss wie ein Angreifer denken. Was würden Sie versuchen, wenn Sie diesen Endpoint brechen wollten?
Die APIs, die Sie heute bauen, sind die Angriffsfläche von morgen. Entwerfen Sie sie von Anfang an defensiv.