API-Sicherheit: Authentifizierung, Autorisierung & Exploits

Warum APIs ein Hauptangriffsziel sind

APIs sind zum dominanten Architekturmuster für moderne Anwendungen geworden – mobile Clients, Single-Page-Apps, Microservices und Drittanbieter-Integrationen kommunizieren alle über sie. Diese Allgegenwärtigkeit macht sie zu einem attraktiven Ziel: Ein einziger anfälliger API-Endpunkt kann Daten von Millionen von Benutzern exponieren, Authentifizierung umgehen oder unbefugten administrativen Zugriff gewähren. OWASP pflegt eine eigene API Security Top 10-Liste speziell deshalb, weil Webanwendungs-Schwachstellen API-spezifische Risiken nicht vollständig erfassen.

Authentifizierung: Identität auf der API-Ebene nachweisen

API-Schlüssel

API-Schlüssel sind der einfachste Authentifizierungsmechanismus – ein statisches Geheimnis, das mit dem Client geteilt wird. Sie sind für Server-zu-Server-Kommunikation geeignet, bei der der Client ein vertrauenswürdiges Backend-System ist. Wichtige Praktiken:

• Behandeln Sie API-Schlüssel wie Passwörter: protokollieren Sie sie niemals, fügen Sie sie niemals in URLs ein (verwenden Sie den Authorization-Header), legen Sie sie niemals in der Versionskontrolle ab
• Stellen Sie pro-Client-Schlüssel aus, damit Sie einzelne Schlüssel widerrufen können, ohne andere zu stören
• Setzen Sie Ablaufdaten und rotieren Sie Schlüssel regelmäßig
• Begrenzen Sie Schlüssel auf die minimal erforderlichen Berechtigungen

JWT-basierte Authentifizierung

JWTs (JSON Web Tokens) kodieren Angaben, die der Server ohne Datenbankabfrage überprüfen kann, was sie bei zustandslosen APIs beliebt macht. Ein JWT besteht aus Header, Nutzlast und Signatur: header.payload.signature, jeweils Base64URL-kodiert.

Kritische Validierungsschritte:

1. Signatur mit dem korrekten Algorithmus überprüfen (alg:none ablehnen)
2. Überprüfen, ob iss (Aussteller) Ihrer erwarteten Autorität entspricht
3. Überprüfen, ob aud (Zielgruppe) Ihre API ist
4. exp (Ablauf) prüfen – abgelaufene Token ablehnen
5. nbf (nicht vor) prüfen, falls vorhanden

Vertrauen Sie nie dem alg-Feld im Token-Header, um die Validierungslogik zu bestimmen – fixieren Sie immer den erwarteten Algorithmus serverseitig.

OAuth-Scopes für die Autorisierung

Für benutzerorientierte APIs verwenden Sie OAuth 2.0 mit fein granularen Scopes: read:profile, write:orders, admin:billing. Jeder API-Endpunkt sollte überprüfen, ob das präsentierte Token den erforderlichen Scope enthält. Ein gültiges Token bedeutet nicht Zugriff auf alles.

OWASP API Security Top 10: Die kritischen Risiken

Fehlerhafte objektbezogene Autorisierung (BOLA)

BOLA – auch IDOR (Insecure Direct Object Reference) genannt – ist konsistent das API-Sicherheitsrisiko Nr. 1. Es tritt auf, wenn ein API-Endpunkt eine Objekt-ID in der Anfrage akzeptiert, aber nicht überprüft, ob der anfragende Benutzer tatsächlich Eigentümer dieses Objekts ist:

GET /api/orders/12345  →  gibt Bestellung 12345 zurück
GET /api/orders/12346  →  gibt die Bestellung eines anderen Benutzers zurück (BOLA!)

Verteidigung: Überprüfen Sie bei jedem objektzugriffenden Endpunkt, ob der authentifizierte Benutzer eine Beziehung zum angeforderten Objekt hat. Verlassen Sie sich niemals nur auf die Objekt-ID.

Fehlerhafte Funktionsebenen-Autorisierung

Administrative Funktionen sind an vorhersehbaren URLs verfügbar, verlassen sich aber auf clientseitiges Verstecken anstatt serverseitige Durchsetzung:

POST /api/admin/deleteUser  →  für reguläre Benutzer zugänglich

Verteidigung: Erzwingen Sie rollenbasierte Zugangskontrolle auf jedem Endpunkt, serverseitig. Testen Sie regelmäßig alle Endpunkte, unabhängig davon, ob sie für Ihre Rolle in der Benutzeroberfläche erscheinen.

Fehlerhafte Objekteigenschaften-Autorisierung

Eine API kann korrekt einschränken, welche Objekte Sie zugreifen können, aber interne Felder innerhalb dieser Objekte exponieren oder deren Änderung ermöglichen:

PUT /api/users/me  {"role": "admin"}  →  Mass-Assignment-Schwachstelle

Verteidigung: Verwenden Sie explizite Allowlists für Felder, die pro Endpunkt gelesen oder geschrieben werden können. Übergeben Sie niemals Request-Body-Objekte direkt an ORM-Methoden (z. B. Rails update(params[:user]) ohne permit).

Unbegrenzte Ressourcennutzung

Ohne Rate Limiting kann ein einzelner Client die Rechen-, Datenbankverbindungs- oder Drittanbieter-Dienstkapazität Ihrer API erschöpfen:

• Implementieren Sie Rate Limiting pro Benutzer, pro IP und pro API-Schlüssel
• Geben Sie 429 Too Many Requests mit Retry-After-Headern zurück
• Begrenzen Sie die Request-Body-Größe, um DoS durch überdimensionierte Nutzlasten zu verhindern
• Paginieren und begrenzen Sie Ergebnisse: geben Sie niemals unbegrenzte Sammlungen zurück
• Wenden Sie Tiefenbeschränkungen für GraphQL-APIs an

Verwenden Sie Tools wie nginx's limit_req-Modul, AWS API Gateway Throttling oder dedizierte API-Gateways (Kong, Envoy) für Rate Limiting.

Sicherheitsfehlkonfiguration

Häufige API-Fehlkonfigurationen umfassen:

• CORS auf Access-Control-Allow-Origin: * auf authentifizierten Endpunkten gesetzt
• Ausführliche Fehlermeldungen, die Stack-Traces, Datenbankabfragen oder interne Pfade exponieren
• HTTP-Methoden nicht eingeschränkt (PUT/DELETE aktiviert, wo nur GET/POST sein sollten)
• Fehlende HTTPS-Erzwingung
• Swagger/OpenAPI-Dokumentation öffentlich in der Produktion exponiert

Sensible Geschäftslogik-Fehler

Nicht alle API-Schwachstellen sind technischer Natur – einige nutzen die Geschäftslogik selbst aus:

• Einen Rabatt-Coupon-Code mehrmals anwenden
• Einen negativen Betrag übertragen, um Guthaben hinzuzufügen
• Erforderliche Zahlungsschritte überspringen, indem ein späterer API-Endpunkt direkt aufgerufen wird

Diese erfordern Domänenwissen zum Auffinden und können nicht allein durch automatisierte Scanner erkannt werden. Fügen Sie Geschäftslogiktests in Ihre API-Sicherheitsüberprüfungen ein.

Praktische API-Sicherheitshärtung

• Verwenden Sie HTTPS überall und leiten Sie HTTP auf HTTPS um; setzen Sie den Strict-Transport-Security-Header
• Validieren Sie alle Eingaben – weisen Sie unerwartete Felder zurück, validieren Sie Typen, Bereiche und Formate
• Geben Sie minimale Daten zurück – fügen Sie keine internen IDs, serverseitige Zeitstempel oder Systemmetadaten in Antworten ein
• Protokollieren Sie alle API-Aufrufe mit genügend Kontext (Benutzer-ID, Endpunkt, Antwortcode, Dauer) für forensische Analysen
• Verwenden Sie ein API-Gateway für zentralisierte Authentifizierung, Rate Limiting, Protokollierung und Bedrohungserkennung
• Testen Sie mit OWASP ZAP oder Burp Suite gegen Ihre eigene API-Dokumentation – jeder Endpunkt in Ihrer OpenAPI-Spezifikation sollte auf Auth-Bypass und BOLA getestet werden