API Security — OWASP API Top 10, OAuth-Missbrauch & GraphQL-Angriffe

OWASP API Top 10 — die kritischsten API-Schwachstellen

API1:2023 — Broken Object Level Authorization (BOLA) ist die häufigste und gefährlichste API-Schwachstelle. Das Prinzip: Ein authentifizierter Benutzer ändert eine Objekt-ID in der API-Anfrage und erhält Zugriff auf Daten anderer Benutzer. Beispiel: GET /api/v1/users/123/orders → ändere 123 zu 124 → Bestellungen eines anderen Benutzers. Realer Fall: Optus-Datenleck (2022) — ein BOLA-Bug in einer öffentlichen API exponierte die persönlichen Daten von 9,8 Millionen Kunden (Name, Adresse, Geburtsdatum, Reisepass-/Führerscheinnummer). Der Angreifer iterierte einfach über fortlaufende Customer-IDs.

API2:2023 — Broken Authentication: Schwache API-Authentifizierung: API-Keys ohne Rotation, JWT-Tokens ohne Signaturvalidierung (alg: none-Angriff), fehlende Rate Limits auf Login-Endpoints. API3:2023 — Broken Object Property Level Authorization: Die API gibt mehr Daten zurück als notwendig (Excessive Data Exposure) oder erlaubt das Ändern von Eigenschaften, die der Benutzer nicht ändern darf (Mass Assignment). Beispiel Mass Assignment: PUT /api/v1/users/me mit {"name": "John", "role": "admin"} — wenn die API das role-Feld nicht explizit filtert, wird der Benutzer zum Admin.

• API4 — Unrestricted Resource Consumption: Keine Rate Limits, keine Payload-Größenbegrenzung, keine Pagination. Ein Angreifer kann: DoS durch massenhafte API-Aufrufe, Kosten-Explosion bei Cloud-APIs (z. B. SMS-Versand-API ohne Rate Limit → Millionen SMS → enorme Rechnung), Data Scraping durch Iteration über alle Datensätze. Verteidigung: Rate Limiting (Token Bucket oder Sliding Window), Pagination erzwingen (max. 100 Ergebnisse pro Seite), Request-Size-Limits, Timeout für langlaufende Queries.
• API5 — Broken Function Level Authorization: Administrative API-Endpunkte sind für normale Benutzer erreichbar. Beispiel: GET /api/v1/users (normal) vs. DELETE /api/v1/admin/users/123 (Admin). Wenn der Admin-Endpunkt keine Rollenprüfung hat, kann jeder authentifizierte Benutzer Admin-Funktionen aufrufen. Häufig bei API-Versionen: /api/v2/ hat Authorization, /api/v1/ (veraltet, aber noch aktiv) nicht. Verteidigung: Zentrales Authorization-Middleware (nicht in jedem Endpunkt einzeln), Deny-by-Default (jeder Endpunkt ist gesperrt, bis explizit freigegeben).
• API6 — SSRF (Server-Side Request Forgery): Wenn eine API URLs als Parameter akzeptiert und serverseitig abruft (z. B. Webhook-URLs, URL-Previews, PDF-Generierung aus URLs), kann ein Angreifer interne Dienste aufrufen: {"webhook_url": "http://169.254.169.254/latest/meta-data/"} → AWS-Metadata-Service → IAM-Credentials stehlen. Capital One Breach (2019): SSRF über eine fehlkonfigurierte WAF → AWS-Metadata → IAM-Rolle → S3-Buckets mit 100 Millionen Kundendaten. Verteidigung: Allowlist für ausgehende URLs, IMDSv2 (erfordert Token für Metadata-Zugriff), Netzwerksegmentierung.
• API8 — Security Misconfiguration: Die „Catch-all“-Kategorie: CORS zu offen (Access-Control-Allow-Origin: * mit Credentials), Verbose Error Messages (Stack Traces, SQL-Fehlermeldungen an den Client), unnötige HTTP-Methoden (PUT, DELETE auf Read-Only-Endpoints), Default Credentials auf API-Management-Portalen (Kong, Tyk, Apigee), fehlende TLS (API über HTTP erreichbar). Automatisierte Erkennung: Nuclei (ProjectDiscovery) mit API-Security-Templates, OWASP ZAP API-Scan.

GraphQL & OAuth Angriffe — die modernen API-Vektoren

GraphQL (Facebook, 2015) ermöglicht es Clients, präzise die Daten anzufordern, die sie benötigen — aber diese Flexibilität führt zu einzigartigen Sicherheitsrisiken: Introspection — standardmäßig kann jeder Client das vollständige API-Schema abfragen ({ __schema { types { name fields { name type { name } } } } }), inklusive aller Typen, Felder und Beziehungen. Ein Angreifer erhält damit eine vollständige Karte der API — inklusive interner/administrativer Felder, die in der Dokumentation nicht erwähnt werden. Verteidigung: Introspection in Production deaktivieren.

OAuth 2.0 ist das Standard-Autorisierungsprotokoll für APIs — aber die Komplexität der verschiedenen Grant Types (Authorization Code, Client Credentials, Device Code, Implicit — deprecated) führt häufig zu Fehlkonfigurationen. Die häufigsten OAuth-Schwachstellen 2026: Redirect URI Manipulation (Open Redirect → Authorization Code stehlen), PKCE nicht erzwungen (Authorization Code Interception auf mobilen Apps), Token Storage im LocalStorage (XSS → Token stehlen — sollte in HttpOnly Cookies sein), Scope Over-Provisioning (Token mit mehr Berechtigungen als nötig).

• GraphQL-spezifische Angriffe: Batching Attacks: GraphQL erlaubt mehrere Queries in einer Anfrage — ein Angreifer kann tausende Mutations in einem Batch senden und Rate Limits umgehen (die pro HTTP-Request, nicht pro GraphQL-Operation zählen). Deep Nesting / Query Complexity: { user { friends { friends { friends { ... } } } } } — exponentielles Datenwachstum, das den Server überlastet (DoS). Alias-basiertes Brute-Forcing: { a1: login(user:"admin", pass:"pass1") a2: login(user:"admin", pass:"pass2") ... } — hunderte Login-Versuche in einer einzigen Anfrage. Verteidigung: Query-Depth-Limit, Query-Complexity-Analyse, Operations-basiertes Rate Limiting.
• JWT-Schwachstellen (JSON Web Tokens): Algorithm None Attack: Der Angreifer ändert den JWT-Header auf {"alg": "none"} und entfernt die Signatur — wenn der Server den Algorithmus aus dem Token liest (statt ihn serverseitig festzulegen), akzeptiert er den unsignierten Token. Algorithm Confusion (RS256 → HS256): Der Server verwendet RSA (asymmetrisch), der Angreifer ändert auf HMAC (symmetrisch) und signiert den Token mit dem öffentlichen RSA-Schlüssel als HMAC-Secret. JWK Injection: Der Angreifer fügt seinen eigenen Public Key in den JWT-Header ein und signiert den Token mit seinem Private Key. Verteidigung: Algorithmus serverseitig festlegen, nie aus dem Token lesen.
• OAuth Authorization Code Interception: Auf mobilen Apps kann der Authorization Code abgefangen werden, wenn die App Custom URL Schemes für den Redirect verwendet (z. B. myapp://callback?code=ABC123) — eine bösartige App kann denselben URL Scheme registrieren und den Code stehlen. Lösung: PKCE (Proof Key for Code Exchange, RFC 7636) — der Client generiert einen zufälligen code_verifier, sendet den Hash (code_challenge) bei der Authorization-Anfrage, und präsentiert den Original-Verifier beim Token-Exchange. Ein Angreifer, der nur den Code abfängt, kann den Verifier nicht rekonstruieren. PKCE ist 2026 für alle OAuth-Flows Pflicht (auch für Web-Apps — Best Current Practice RFC 9449).
• API Key Exposure & Secret Scanning: Hardcoded API Keys in Quellcode, Konfigurationsdateien oder Client-Side JavaScript sind 2026 immer noch die Nr. 1 API-Credential-Schwachstelle. GitHub hat 2024 über 12 Millionen Secrets in öffentlichen Repositories gefunden. GitHub Secret Scanning (kostenlos für Public Repos, GitHub Advanced Security für Private) erkennt über 200 Secret-Typen (AWS Keys, Azure Connection Strings, Stripe API Keys). Zusätzliche Tools: TruffleHog (Open Source, Git-History-Scan), Gitleaks (CI/CD-Integration). Verteidigung: Environment Variables, Vault (HashiCorp), Azure Key Vault, AWS Secrets Manager.

API Defense Strategy — Schutzmaßnahmen 2026

Eine robuste API-Security-Strategie basiert auf fünf Säulen: 1) API Discovery — Sie können nur schützen, was Sie kennen. Inventarisieren Sie alle APIs (intern, extern, Partner, Legacy). Tools: API-Gateway-Logs analysieren, Traffic-Analyse, Code-Scanning. 2) Authentication & Authorization — OAuth 2.0 + PKCE, JWT mit serverseitigem Algorithmus, API Keys nur als Identifikation (nicht als einzige Auth). 3) Input Validation — Schema-Validierung (OpenAPI Spec), Content-Type-Prüfung, Payload-Größenlimits. 4) Rate Limiting & Throttling — pro Benutzer, pro IP, pro Endpunkt. 5) Monitoring & Anomalie-Erkennung — Baseline des normalen API-Nutzungsverhaltens, Alerts bei Abweichungen.

• API Gateway als zentrale Sicherheitsschicht: Kong (Open Source + Enterprise), Amazon API Gateway, Azure API Management, Apigee (Google). Funktionen: Authentication Enforcement (OAuth, mTLS, API Key), Rate Limiting, Request/Response Transformation (sensitive Felder aus Responses filtern), Schema Validation (gegen OpenAPI Spec prüfen), WAF-Integration, Logging & Analytics. Best Practice: Alle APIs durch ein Gateway routen — keine direkte Client-zu-Backend-Kommunikation.
• API-Pentesting-Methodik: 1) Reconnaissance: API-Dokumentation, OpenAPI/Swagger-Dateien, GraphQL Introspection, JavaScript-Quellcode nach Endpunkten durchsuchen. 2) Authentication Testing: Default Credentials, Token-Manipulation (JWT alg:none, Expired Tokens), OAuth-Flow-Schwachstellen. 3) Authorization Testing: BOLA (IDs ändern), Privilege Escalation (Admin-Endpunkte), Horizontal/Vertical Bypass. 4) Input Validation: Injection (SQL, NoSQL, Command), SSRF, XXE. 5) Rate Limit Testing: Brute Force, Enumeration, Scraping. Tools: Burp Suite (Autorize-Extension für BOLA), Postman (Collection Runner), Nuclei (API-Templates).
• Shift-Left API Security: API-Sicherheit beginnt im Entwicklungsprozess: OpenAPI Spec als Contract — die API-Spezifikation wird VOR der Implementierung definiert und Security-reviewed. API Linting: Spectral (Stoplight) prüft die OpenAPI-Spec auf Security-Best-Practices (fehlende Auth, keine Rate Limits, übermäßige Datenexposition). DAST in CI/CD: OWASP ZAP oder Nuclei als API-Scanner in die Build-Pipeline integrieren — jeder API-Change wird automatisch auf Schwachstellen getestet. API Versioning: Alte API-Versionen mit bekannten Schwachstellen zeitnah dekommissionieren.
• Runtime API Protection (WAAP): WAAP (Web Application and API Protection) ist die Evolution der WAF für APIs: Positive Security Model — nur Requests, die dem API-Schema entsprechen, werden durchgelassen (statt Blocklist-basierter WAF). Bot Management — API-Scraping und Credential Stuffing erkennen und blockieren. Behavioral Analysis — Anomalie-Erkennung basierend auf normalem API-Nutzungsverhalten (ungewöhnliche Endpunkte, ungewöhnliche Abfragereihenfolge). Produkte: Cloudflare API Shield, Akamai API Security, Salt Security (API-spezifische Anomalie-Erkennung), 42Crunch (API-Conformance-Testing).