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.