APIs sind der neue Perimeter
Jedes moderne SaaS ist eine API mit aufgeklebter Oberfläche. Deine Mobile-App, deine Web-App, deine Integrationen — sie alle kommunizieren mit derselben REST- oder GraphQL-API. Und Angreifer wissen das.
Die OWASP API Security Top 10 ist für SaaS-Produkte relevanter geworden als die ursprüngliche OWASP Top 10. Hier sind die 5 Risiken, auf die ich bei Pentests am häufigsten stoße.
1. Broken Object-Level Authorization (API1:2023)
Was es ist: Ein API-Endpunkt gibt Daten basierend auf einer vom Nutzer übermittelten ID zurück, ohne zu prüfen, ob der anfragende Nutzer diese Ressource besitzt.
Reales Beispiel: GET /api/invoices/1452 gibt Rechnung #1452 zurück. Aber der Nutzer von Unternehmen A ändert die ID auf 1453 und erhält die Rechnung von Unternehmen B — komplett mit Rechnungsadresse, VAT-ID und Einzelposten.
Der Fix: Vertraue niemals der Objekt-ID aus der URL. Jede Datenbankabfrage muss den Mandanten-/Eigentümerkontext des Nutzers enthalten. Pseudocode:
// Falsch
SELECT * FROM invoices WHERE id = $url_id;
// Richtig
SELECT * FROM invoices WHERE id = $url_id AND tenant_id = $session_tenant_id;
2. Broken Authentication (API2:2023)
Was es ist: Schwache oder fehlende Authentifizierung an API-Endpunkten, oder Authentifizierung, die leicht zu umgehen ist.
Reales Beispiel: Ein Admin-Endpunkt unter /api/admin/users prüft auf ein gültiges JWT — akzeptiert aber Tokens, die mit Algorithmus none oder mit einem leeren Secret signiert sind. Oder schlimmer: Die Staging-Umgebung hat dasselbe JWT-Secret wie Produktion, hartcodiert in einer .env.example-Datei, die im öffentlichen Repo committed wurde.
Der Fix:
- Whitelisting von JWT-Algorithmen (nur RS256/HS256, niemals
none) - Secrets zwischen Umgebungen rotieren
- Rate Limiting für Login- und Token-Refresh-Endpunkte
3. Broken Object Property Level Authorization (API3:2023)
Was es ist: Die API akzeptiert mehr Felder im Request-Body als beabsichtigt. Mass Assignment erlaubt Nutzern, Felder zu setzen, die sie nicht setzen dürften.
Reales Beispiel: Ein „Profil aktualisieren"-Endpunkt akzeptiert POST /api/users/me mit einem JSON-Body. Das Backend aktualisiert blind jedes Feld im Request:
{
"name": "Angreifer",
"role": "admin",
"plan": "enterprise",
"is_verified": true
}Der Fix: Whitelisting erlaubter Felder. Verwende niemals $model->update($request->all()). Liste immer explizit auf, welche Felder aktualisiert werden dürfen:
$user->fill($request->only(['name', 'avatar', 'timezone']));4. Unrestricted Access to Sensitive Business Flows (API6:2023)
Was es ist: API-Endpunkte, die geschäftskritische Aktionen ohne Missbrauchsschutz ausführen.
Reales Beispiel: Ein „Freunde-werben"-Programm gibt beiden Nutzern 10 € Guthaben. Kein Rate Limiting, keine Duplikatsprüfung. Ein Angreifer schreibt ein Skript, das 1.000 Fake-Accounts erstellt und 10.000 € Guthaben einsammelt.
Der Fix: Modelliere den Geschäftsschaden von API-Missbrauch. Wenn ein Endpunkt Geld, Guthaben oder Zugriff bewegt — füge Rate Limiting, Duplikatserkennung und Anomalie-Monitoring hinzu.
5. Server-Side Request Forgery (API7:2023)
Was es ist: Die API akzeptiert eine URL als Eingabe und führt eine Anfrage dorthin aus. Angreifer nutzen dies, um interne Dienste anzugreifen.
Reales Beispiel: Ein Webhook-Registrierungsendpunkt nimmt https://example.com/webhook entgegen und der Server prüft, ob die URL erreichbar ist. Ein Angreifer liefert http://169.254.169.254/latest/meta-data/ (AWS Metadata-Endpunkt) und erhält AWS-Zugangsdaten in der Antwort.
Der Fix: Lass von Nutzern übermittelte URLs niemals interne IP-Bereiche erreichen. Verwende wenn möglich eine URL-Allowlist. Blockiere Anfragen an 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 und 127.0.0.0/8.
---
Das Muster
Erkennst du das Muster in allen 5 Risiken? Vertrauensgrenzen. Deine API vertraut dem Client, die richtigen IDs, die richtigen Felder, die richtigen URLs zu senden. Angreifer nutzen dieses Vertrauen aus.
Jeder API-Endpunkt sollte sich fragen: „Ist die Entität, die diese Anfrage stellt, autorisiert, auf die von dieser Anfrage anvisierte Ressource zuzugreifen?" Wenn die Antwort kein eindeutiges Ja ist, hast du eine Schwachstelle.
Was auf dieser Liste fehlt
Injection (SQLi, NoSQLi) und Security Misconfiguration sind immer noch verbreitet — aber sie wurden von modernen Frameworks mit eingebauter Parametrisierung und sicheren Defaults zurückgedrängt. Die obigen Risiken sind die, die Frameworks nicht für dich lösen. Authorization liegt in deiner Verantwortung.