Was ist ein API-Security-Audit?

Was ist ein API-Security-Audit?

Ein API-Security-Audit ist die systematische Überprüfung der API-Oberfläche einer Organisation auf Schwachstellen — Authentifizierungs-Schwächen, Autorisierungs-Fehler, Input-Validierungs-Lücken, Rate-Limiting-Lücken, exponierte sensible Daten und den Rest der OWASP-API-Security-Top-10. Das Audit produziert eine priorisierte Liste von Findings mit Schweregrad, Exploit-Komplexität und Remediation-Anleitung. Gut gemacht ist ein API-Security-Audit der effektivste Weg, echtes Risiko in einem modernen Web-Stack ans Licht zu bringen — die meisten modernen Apps sind zu 80%+ API-Oberfläche, sodass APIs die Security-Exposition konzentrieren.

API-Security-Audits kommen in drei Geschmäckern: intern (dein Security-Team führt Tools + manuelle Review), Third-Party (Spezialist-Firmen wie NCC Group, Bishop Fox, Trail of Bits — meist jährlich oder pre-Launch) und kontinuierlich automatisiert (Tools wie Salt, Noname, Wallarm, die Produktions-Traffic kontinuierlich scannen). Die meisten reifen Orgs nutzen alle drei: kontinuierlich automatisiert für Baseline, Third-Party jährlich für Tiefe, intern für laufende Remediation.

Die OWASP API Security Top 10 (2023-Edition)

Die Referenz-Liste, gegen die jedes API-Security-Audit prüft:

1. Broken Object Level Authorization (BOLA) — häufigste API-Schwachstelle. GET /users/123 gibt Daten von User 123 zurück, ohne zu prüfen, ob der Anrufer erlaubt ist.
2. Broken Authentication — schwache Token-Validierung, Credential-Wiederverwendung, fehlende MFA.
3. Broken Object Property Level Authorization — Anrufer kann Objekt-Felder lesen oder modifizieren, die er nicht sollte.
4. Unrestricted Resource Consumption — kein Rate-Limiting, kein Body-Size-Cap; ermöglicht DoS.
5. Broken Function Level Authorization — Admin-Endpoints für Nicht-Admins zugänglich.
6. Unrestricted Access to Sensitive Business Flows — Automatisierung kann Inventar leeren, Coupons missbrauchen etc.
7. Server-Side Request Forgery (SSRF) — vom Nutzer kontrollierte URL, server-seitig gefetcht, erreicht interne Services.
8. Security Misconfiguration — Debug-Mode in Prod, Default-Creds, ausführliche Fehler.
9. Improper Inventory Management — alte API-Versionen unüberwacht laufend ("Schatten-APIs").
10. Unsafe Consumption of APIs — Drittanbieter-APIs ohne Validierung vertraut.

Was ein API-Security-Audit abdeckt

Authentifizierung + Autorisierung

• Token-Validierung: Signatur, Ablauf, Scope, Audience.
• Session-Management: Rotation, Widerruf, Idle-Timeout.
• Autorisierungs-Checks an jedem Endpoint, einschließlich Object-Level (BOLA).
• Rollen- + Permission-Grenzen konsistent durchgesetzt.

Input-Validierung

• SQL-Injection, NoSQL-Injection, Command-Injection, LDAP-Injection.
• SSRF / XXE / Deserialisierungs-Risiken.
• Body-Size-Limits + Content-Type-Durchsetzung.
• JSON-Schema-Validierung.

Rate-Limiting + Missbrauchs-Prävention

• Pro-Nutzer- / Pro-IP- / Pro-Endpoint-Rate-Limits.
• Brute-Force-Schutz auf Auth-Endpoints.
• CAPTCHA + Bot-Detection, wo angemessen.

Daten-Exposition

• Response-Shaping (keine Passwort-Hashes, interne IDs zurückgeben).
• Logging-Disziplin (keine Tokens, PII loggen).
• Fehlermeldungs-Hygiene (keine Stack-Traces, Query-Pläne leaken).

Inventar + Lebenszyklus

• Alle Endpoints katalogisieren (inkl. v1, v2, intern). Siehe API-Sprawl.
• Alte Versionen nach Plan abschalten.
• Schatten-APIs erkennen (deployed ohne durch Gateway zu gehen).

Wie ein typisches Audit abläuft

1. Inventar-Phase. Alle APIs katalogisieren (Gateway-Logs, OpenAPI-Specs, Code-Grep, Traffic-Discovery).
2. Automatisierter Scan. Tools wie OWASP ZAP, Burp Suite Pro, StackHawk, Salt führen automatisierte Tests aus.
3. Manuelles Testing. Auditoren zielen manuell auf die OWASP Top 10 — automatisierte Tools verpassen BOLA, Business-Logic-Missbrauch und komplexe Auth-Flows.
4. Findings + Schweregrad-Scoring. CVSS oder proprietäres Risiko-Scoring; meist CRITICAL/HIGH/MEDIUM/LOW.
5. Remediation. Engineering-Fixes, mit Tracking bis verifiziert.
6. Re-Test. Verifiziere, dass Findings tatsächlich geschlossen sind; häufig finden sich Regressionen.
7. Report. Intern + Executive Summary; manchmal eine sanitisierte öffentliche Zusammenfassung für Kunden-/Regulator-Review.

Häufige API-Security-Audit-Findings

• BOLA auf REST-Ressourcen. Mass-Assignment / direkte ID-Exposition ohne Zugriffs-Checks.
• Ausführliche Fehler, die Stack-Traces leaken. Production sollte niemals interne Stack-Traces exponieren.
• Rate-Limiting nur am Gateway. Wenn Nutzer Origin direkt treffen können, sind Rate-Limits bedeutungslos.
• JWT-Validierungs-Lücken. Signaturverifikation überspringen, alg: none akzeptieren, schwache HMAC-Keys.
• OAuth-Scope-Mishandling. Token gewährt mehr Zugriff als beabsichtigt; Refresh-Tokens laufen nie ab.
• Fehlendes TLS auf internen Calls. Innerhalb der VPC ≠ sicher; interne Calls verdienen mTLS oder mindestens authentifiziertes TLS.
• Unsichere Deserialisierung. Besonders in älteren Java / .NET / Python-Pickle-Pfaden.
• Fehlende CORS / CSRF-Schutz auf Browser-zugewandten Endpoints.

FAQ: API-Security-Audits

Wie oft sollte ich ein API-Security-Audit laufen lassen?

Kontinuierliches automatisiertes Scanning die ganze Zeit. Interne Review pro Release. Third-Party jährlich + vor jedem großen Launch. Verlasse dich nicht nur auf jährlich — APIs ändern sich zu schnell.

Was ist der Unterschied zwischen einem API-Security-Audit und einem Pen-Test?

Penetration-Testing ist breiter (Netzwerk, Infrastruktur, Social-Engineering). Ein API-Security-Audit ist API-spezifisch. Die meisten Enterprises führen beide aus — Pen-Tests jährlich, API-Audits pro Release/kontinuierlich.

Wie lange dauert ein API-Security-Audit?

Intern automatisiert: Stunden. Third-Party umfassend: 2-6 Wochen für eine typische SaaS-API-Oberfläche. Zeit skaliert mit API-Anzahl + Komplexität.

Was kostet ein API-Security-Audit?

Third-Party umfassend: 20k-200k $ je nach Scope + Firmen-Reputation. Kontinuierliche automatisierte Tools: 20k-200k $/Jahr. Interne Arbeit: variabel.

Wie bereite ich mich auf ein Audit vor?

Aktuelle OpenAPI-Specs, aktuelles API-Inventar, kürzliches Threat-Model, Liste bekannter Issues, Zugang für die Auditoren (Test-Credentials, Gateway-Zugriff, Code-Repo). Auditoren hassen es, bei null zu starten.

Was ist mit internen-only APIs?

Auditiere sie auch. "Intern" bedeutet nicht sicher — die meiste laterale Bewegung in Breaches passiert durch interne APIs. Wende die gleichen Standards an.

Wie verhält sich API-Security-Audit zu SOC 2 / ISO 27001?

Beide Frameworks erfordern eine Form von Vulnerability-Management, oft erfüllt durch eine dokumentierte API-Security-Audit-Kadenz. Auditoren werden nach Beweisen für regelmäßiges Testen + Remediation fragen.

Wie LoadFocus zu API-Security-Validierung steht

API-Security-Audits bringen Schwachstellen zu einem Zeitpunkt ans Licht. LoadFocus-API-Monitoring validiert laufende Gesundheit — einschließlich Assertion-Checks, die Regressionen in Auth/AuthZ-Handling fangen (z.B. ein Deploy, der BOLA-Schutz still bricht). API-Lasttest validiert, dass Rate-Limiting und DoS-Schutz unter angriffs-ähnlichen Last-Patterns tatsächlich funktionieren — viele Rate-Limits sehen im Code-Review richtig aus, fallen aber im Maßstab aus.