OWASP API Top 10 konkret

Warum eine eigene API-Liste

Die klassische Web-Top-10 ist auf Browser-basierte Anwendungen ausgerichtet: HTML-Output, Cookie-Sessions, Form-Submissions, XSS, CSRF. APIs funktionieren anders:

• Maschine-zu-Maschine-Kommunikation ohne Browser-Layer.
• JSON / GraphQL / gRPC statt HTML.
• Token-basierte Authentifizierung (JWT, OAuth, API-Keys) statt Cookies.
• Massen-Aufrufe durch Mobile- und Server-Clients.
• Direkte Daten-Endpunkte ohne UI-Schicht, die Logik enforcen würde.

Daraus entstehen Angriffs-Muster, die in der Web-Top-10 nur gestreift werden: Object-Level-Authorization als zentrale Schwäche, Massen-Daten-Exfiltration durch ungesicherte Endpunkte, Geschäfts-Flow-Manipulation über parallele Requests. OWASP veröffentlicht die API Top 10 seit 2019, aktualisiert 2023 — die nächste Edition wird voraussichtlich 2027 kommen.

API1 — Broken Object Level Authorization (BOLA)

Was es ist: Die häufigste API-Schwachstelle überhaupt. Authentifizierter Nutzer A ruft GET /api/orders/12345 auf — und bekommt die Bestellung 12345, obwohl sie Nutzer B gehört. Authentifizierung läuft (User A ist eingeloggt), aber Object-Owner-Check fehlt.

Konkretes Beispiel:

// Schadhaft
app.get('/api/orders/:id', authenticated, (req, res) => {
  const order = db.orders.findOne({ id: req.params.id });
  res.json(order); // gibt JEDE Bestellung zurück
});

// Sicher
app.get('/api/orders/:id', authenticated, (req, res) => {
  const order = db.orders.findOne({
    id: req.params.id,
    userId: req.user.id  // Owner-Check!
  });
  if (!order) return res.status(404).send();
  res.json(order);
});

Verbreitete Varianten:

• Sequenzielle IDs (/orders/1, /orders/2, ...) — Angreifer iteriert durch.
• UUIDs sind kein Schutz — UUIDs verhindern Erraten, nicht den fehlenden Owner-Check. Wer die UUID irgendwoher kennt (Mail-Link, Browser-History, Log-Leck), kommt rein.
• Indirekte Referenzen über Header oder Body ({ "userId": 42 }) — Angreifer ändert den Wert.

Schutz-Pattern:

• Owner-Check pro Anfrage (idealerweise in einem Middleware-Layer).
• Tenant-Scoping in Queries — DB-Filter erzwingt, dass nur eigene Daten zurückkommen.
• Test-Strategie: Cross-Tenant-Read-Tests — pro API-Endpunkt: kann User A Daten von User B sehen?

Reale Fälle: Optus 2022 (10 Mio. Kunden), T-Mobile 2023, viele Fintechs mit BOLA-Welle 2022–2024.

API2 — Broken Authentication

Was es ist: Schwächen in der Authentifizierungs-Kette der API. Klassiker: JWT-Probleme, schwache Token-Generierung, fehlende Anti-Brute-Force.

Konkrete Schwächen:

• JWT alg=none akzeptiert — Token ohne Signatur wird angenommen.
• JWT-Algorithm-Confusion — Token mit RS256-Header wird mit Public-Key als HMAC-Secret validiert (klassischer Bug).
• Endlos-gültige Tokens ohne Rotation.
• Refresh-Token ohne Revocation — gestohlener Token bleibt gültig.
• Login-Endpunkte ohne Rate-Limit — Credential Stuffing möglich.
• Passwort-Reset über Mail-Token ohne Verfallsdatum.
• OAuth-redirect_uri nicht validiert — Authorization-Code-Hijacking.
• OAuth ohne PKCE in Public Clients — Code-Interception möglich.
• API-Keys im URL-Parameter (statt Header) — landen in Server-Logs, Browser-Historie, Referrer.

Schutz:

• JWT-Library mit strikter Algorithmus-Validierung (z. B. jsonwebtoken mit explizitem algorithms-Parameter).
• OAuth 2.1 (RFC 9700) als Default — bringt PKCE-Pflicht, keine Implicit-Flow, sichere Redirect-Validierung.
• Rate-Limits auf Auth-Endpunkten (Login, Reset, Token-Refresh).
• Token in Header (Authorization-Bearer), nicht URL.

Vertieft in auth-grundlagen (Kap 14).

API3 — Broken Object Property Level Authorization (BOPLA)

Was es ist: Neue Kategorie seit 2023, kombiniert frühere Punkte Excessive Data Exposure und Mass Assignment. Zwei Seiten derselben Münze:

Excessive Data Exposure (Lesen): API gibt mehr Felder zurück, als die Anwendung braucht. Frontend filtert clientseitig — Angreifer ruft direkt API auf und sieht alles.

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.de",
  "hashedPassword": "$argon2id$...",
  "isAdmin": false,
  "creditCardLast4": "1234"
}

Frontend zeigt nur name. Angreifer mit Postman sieht hashedPassword und creditCardLast4.

Mass Assignment (Schreiben): API nimmt JSON-Body an und mappt blind auf das Datenmodell. Angreifer setzt Felder, die nur Admins setzen dürfen:

// Schadhaft
app.put('/api/users/:id', authenticated, (req, res) => {
  db.users.update(req.params.id, req.body);
  // Body kann enthalten: { "isAdmin": true }
});

// Sicher
app.put('/api/users/:id', authenticated, (req, res) => {
  const { name, email } = req.body;  // Allowlist
  db.users.update(req.params.id, { name, email });
});

Schutz-Patterns:

• DTOs (Data Transfer Objects) für Input und Output — explizite Allowlist.
• Schema-Validierung mit zod, joi, Pydantic, JSON Schema.
• GraphQL Field-Level-Authorization — pro Feld prüfen, ob Nutzer:in es sehen darf.
• Default-Deny für unbekannte Properties (additionalProperties: false in JSON-Schema).

API4 — Unrestricted Resource Consumption

Was es ist: Fehlende oder unzureichende Limits an Endpunkten, die Server-Ressourcen verbrauchen.

Klassische Beispiele:

• Login-Endpunkt ohne Rate-Limit — Brute Force.
• Such-Endpunkt ohne Pagination-Limit — ?limit=10000000.
• File-Upload ohne Größen-Limit — Disk-Erschöpfung.
• PDF-Generierung-Endpunkt ohne Concurrency-Limit — Memory-Erschöpfung.
• GraphQL-Query-Depth ohne Limit — exponentielle Datenbank-Last ({ users { posts { comments { author { posts { ... }}}}}}).
• Kostspielige Operationen (KI-Inferenz, Geocoding) ohne Quota — Geld-Erschöpfung.

Schutz-Patterns:

• Rate-Limits pro IP / pro User / pro Endpunkt (Token-Bucket, Sliding-Window).
• Pagination Hard-Limits (z. B. max 100 Items pro Request).
• Query-Depth-Limits in GraphQL.
• Concurrency-Limits pro User.
• Cost-Tracking für teure Endpunkte.
• Timeouts pro Operation.

Werkzeuge:

• API-Gateways (Kong, Tyk, AWS API Gateway) mit Rate-Limit-Plugins.
• Library-seitig (express-rate-limit, slowapi für FastAPI, Bucket4j für Java).
• Redis als verteilter Rate-Limit-Speicher.

Vertieft in rate-limiting-und-throttling (Kap 18).

API5 — Broken Function Level Authorization (BFLA)

Was es ist: Wie BOLA, aber auf Funktions-Ebene statt Objekt-Ebene. Normaler Nutzer ruft Admin-Endpunkt auf und bekommt Zugang.

Klassische Beispiele:

• POST /api/users/42/promote-to-admin ohne Admin-Check — jeder eingeloggte User kann sich selbst zum Admin machen.
• DELETE /api/orders/12345 mit nur Authentifizierungs-Check (statt Admin-Check) — Normaler User löscht fremde Bestellungen.
• Versteckte Admin-Endpunkte, die durch Force-Browsing (oder Swagger-Doku-Leck) gefunden werden.

Verbreitete Code-Schwächen:

// Schadhaft — nur Auth-Check, kein Rollen-Check
app.delete('/api/orders/:id', authenticated, (req, res) => {
  db.orders.delete(req.params.id);
});

// Sicher — explizit Admin-Rollen-Check
app.delete('/api/orders/:id', authenticated, requireAdmin, (req, res) => {
  db.orders.delete(req.params.id);
});

Schutz-Pattern:

• Default-Deny — alle Endpunkte verlangen explizite Rolle, sonst 403.
• Policy-Engine (OPA/Rego, Casbin) — zentrale Autorisierung statt verstreute Checks.
• Endpoint-Inventory — wer hat welche Endpunkte, wer ruft sie auf?

API6 — Unrestricted Access to Sensitive Business Flows

Was es ist: Neue Kategorie 2023. Adressiert Missbrauch legitimer API-Funktionen durch Automation: Bot-getriebene Massen-Käufe, Account-Erstellung im großen Stil, Geschenkkarten-Massenkauf, etc.

Klassische Beispiele:

• Sneaker-Drop-Bots — automatisierte Massen-Käufe limitierter Artikel innerhalb von Millisekunden.
• Ticketing-Scraping — Bot kauft alle Konzert-Tickets, verkauft sie auf Zweitmarkt weiter.
• Geschenkkarten-Brute-Force — Bot probiert Codes durch.
• Werbe-Klick-Betrug — gefälschte Klicks generieren Werbe-Einnahmen.
• Massen-Konto-Erstellung für Bonus-Aktionen.

Charakteristik: die Funktion selbst ist legitim — der Missbrauch liegt in Skala und Geschwindigkeit.

Schutz-Patterns:

• CAPTCHA an Risiko-Endpunkten (Login, Anmeldung, Kauf).
• Geräte-Fingerprinting und Verhaltens-Analyse.
• Anti-Bot-Lösungen (Cloudflare Bot Management, Akamai, hCaptcha).
• Rate-Limits pro Identität (nicht nur pro IP — VPN/Proxy umgeht IP-Limits).
• Wartelisten und Queues für hochpreisige limitierte Drops.
• Wirtschaftliche Friktion — z. B. Pflicht-Verifikation, Hold-Time.

Diese Kategorie ist die Anerkennung, dass technisch korrekte APIs trotzdem missbraucht werden können. Bekämpfung verlangt mehr als Code-Härtung.

API7 — Server-Side Request Forgery (SSRF)

Was es ist: API nimmt URLs von Nutzer:in entgegen und schickt Server-seitige Anfragen daran. Angreifer leitet auf interne Services oder Cloud-Metadaten-Endpunkte.

Klassische Beispiele:

• Image-Resize-Service mit URL-Eingabe — Angreifer übergibt http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS-Metadaten).
• Webhook-Konfiguration — Angreifer registriert Webhook auf interne Admin-API.
• PDF-zu-HTML-Renderer lädt externe Bilder — Angreifer liefert URL auf internes Wiki, sieht Inhalt im erzeugten PDF.
• URL-Preview im Mail/Chat — Bot enumeriert interne Services.

Schutz-Patterns:

• Allowlist statt Blocklist für ausgehende URLs (z. B. nur eigene CDN-Domain).
• IMDSv2 in AWS (Token-basiert statt offener Endpoint).
• VPC-/Network-Segmentierung — App-Server haben keinen direkten Zugriff auf interne Admin-Netze.
• DNS-Rebinding-Schutz im URL-Validator (Resolve & Pin, dann verbinden).
• Egress-Filter auf Reverse-Proxy-Ebene.

Vertieft in ssrf-und-cloud-metadata (Kap 18).

Realer Vorfall: Capital One 2019 — über SSRF auf AWS-Metadata-Endpoint kamen 100 Millionen Kunden-Datensätze weg.

API8 — Security Misconfiguration

Was es ist: Wie in der Web-Top-10, spezialisiert auf API-Kontexte:

• Verbose Error Messages mit Stack-Traces.
• CORS-Policy zu weit — Access-Control-Allow-Origin: * mit credentials: true.
• TLS-Konfiguration schwach oder mit deprecated Cipher-Suites.
• Default-Credentials in Admin-Endpunkten.
• Debug-Endpunkte in Production aktiv (/api/debug, /api/healthz mit sensitive Daten).
• Permissive HTTP-Methoden — OPTIONS, TRACE aktiviert.
• Fehlende Security-Header in API-Responses (auch für JSON-APIs wichtig: X-Content-Type-Options: nosniff).

Schutz-Pattern:

• Konfigurations-Hardening-Checklisten (CIS Benchmarks, BSI-Härtungs-Profile).
• Infrastructure-as-Code mit Drift-Detection.
• Automatisierte Konfig-Audits im CI/CD.

API9 — Improper Inventory Management

Was es ist: APIs, die existieren, aber niemand mehr weiß davon. Alte API-Versionen ohne Wartung, vergessene Test-/Staging-Endpunkte, undokumentierte Internal-APIs.

Klassische Beispiele:

• /api/v1/ bleibt online, obwohl /api/v2/ Standard ist — /v1/ hat alte BOLA-Schwächen.
• Staging-API läuft auf öffentlicher IP ohne Authentifizierung.
• Mobile-App-Backend (/api/mobile/) mit anderen Endpunkten als Web-Frontend.
• GraphQL-Introspection in Production aktiv — Angreifer holt das gesamte Schema ab.
• Swagger/OpenAPI-Doku öffentlich verfügbar, listet alle Endpunkte.

Schutz-Pattern:

• API-Inventar pflegen — welche Endpunkte existieren, welcher Version, welche Auth?
• Sunset-Plan für alte API-Versionen.
• API-Discovery-Tools (Salt Security, Noname, 42Crunch, Open-Source: Akto).
• GraphQL-Introspection in Production deaktivieren.
• Externe Asset-Discovery (OWASP Amass, Subdomain-Enumeration).

API10 — Unsafe Consumption of APIs

Was es ist: Neu in 2023. Adressiert nicht deine API als Angriffsziel — sondern dein API-Konsumenten-Risiko. Wenn du externe APIs nutzt, vertraust du ihren Antworten implizit. Was, wenn die externe API kompromittiert ist?

Klassische Beispiele:

• Externe Geocoding-API wird gehackt, gibt manipulierte Adress-Daten zurück, die in deine DB landen.
• Webhook-Empfänger vertraut Inhalten ohne Signatur-Prüfung.
• Drittanbieter-Auth-Service (z. B. Social Login) gibt manipuliertes Profil zurück.
• Externe Library holt Konfiguration dynamisch — manipulierte Antwort führt zu Code-Ausführung.

Schutz-Pattern:

• Externe API-Antworten validieren — Schema-Validierung wie bei User-Input.
• Webhook-Signaturen prüfen (HMAC-SHA-256, Stripe-Style).
• mTLS für kritische Service-zu-Service-Kommunikation.
• Mocked External in Tests — wisse, wie deine API auf unerwartete Antworten reagiert.
• Circuit-Breaker und Timeouts für externe Aufrufe.

Realer Vorfall: SolarWinds 2020 als extreme Variante — Update-Quelle wurde kompromittiert, Tausende Organisationen vertrauten der manipulierten Update-Antwort.

Zusammenfassung in einer Tabelle

Weiterführende Ressourcen

Externe Quellen

• OWASP API Security Project
• OWASP API Top 10 — 2023 Edition
• OWASP REST Security Cheat Sheet
• OWASP GraphQL Cheat Sheet
• Akto – Open Source API Security
• RFC 9700 – OAuth 2.0 Security Best Current Practice
• PortSwigger Web Security Academy
• Schemathesis – API Property-Based Testing

Verwandte Artikel

• OWASP Top 10 Übersicht
• OWASP LLM Top 10
• Business-Logic-Flaws und Race Conditions
• Request Smuggling und Host-Header-Injection
• Autorisierung-Grundlagen (Kap 15)
• IDOR und BOLA (Kap 15)
• Auth-Grundlagen (Kap 14)
• API-Bedrohungen (Kap 18)
• Rate-Limiting und Throttling (Kap 18)
• SSRF und Cloud-Metadata (Kap 18)