Was ist ein API-Sicherheitsaudit?

Was ist ein API-Sicherheitsaudit?

Ein API-Sicherheitsaudit ist eine strukturierte Prüfung von Design, Umsetzung und Konfiguration einer API gegen festgelegte Sicherheitsanforderungen, um Schwachstellen zu finden, bevor ein Angreifer es tut. Es kombiniert eine Bestandsaufnahme der Endpunkte, automatisierte Scans und manuelle Tests und endet in einer priorisierten Befundliste mit Korrekturen und einem erneuten Test.

In der Praxis überschneiden sich die Begriffe. Ein Scan ist automatisiert und findet bekannte Fehlerklassen. Ein Penetrationstest versucht, Schwachstellen auszunutzen. Ein Audit prüft die API gegen einen benannten Standard und nutzt meist beides, dazu einen Blick auf Design, Konfiguration und Dokumentation. Klären Sie Umfang und Begriffe mit dem Dienstleister oder dem Auftraggeber.

Die Standards, gegen die ein Audit prüft

Die meisten Audits beginnen mit den OWASP API Security Top 10 (2023), einer Awareness-Liste der kritischsten API-Risiken (die Namen werden üblicherweise auf Englisch verwendet):

1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs

Für eine tiefere Checkliste führt der OWASP Application Security Verification Standard (ASVS, Version 5.0.0 vom 30. Mai 2025) Sicherheitsanforderungen auf und ist als Grundlage zum Testen technischer Sicherheitskontrollen von Webanwendungen gedacht. Der OWASP Web Security Testing Guide beschreibt, wie man sie testet. Unser Eintrag Top-API-Sicherheitsrisiken erklärt die Risiken selbst, API-Sicherheit das größere Thema.

Ein Beispiel: Broken Object Level Authorization

OWASPs eigenes Szenario für API1 ist eine E-Commerce-API mit einem Endpunkt wie /shops/{shopName}/revenue_data.json. Ein Angreifer holt sich die Liste der Shop-Namen von einem anderen Endpunkt und setzt jeden in die URL ein. Prüft der Server nur, dass der Aufrufer angemeldet ist, nicht aber, dass ihm der Shop gehört, liest das Skript die Umsätze tausender Shops. Ein Scanner erkennt das selten, denn jede Antwort ist ein gültiges 200. Ein Auditor testet es, indem er den Endpunkt als ein Nutzer mit den Kennungen eines anderen aufruft. Die Lösung ist eine Eigentumsprüfung in jeder Funktion, die eine vom Client gelieferte ID annimmt.

So läuft ein Audit ab

1. Umfang und Bestandsaufnahme. Alle APIs und Versionen auflisten: OpenAPI-Dateien, Gateway-Logs, Code und Traffic. Siehe API Discovery und API Sprawl. Einen Endpunkt, von dem niemand weiß, kann man nicht prüfen.
2. Standard wählen. OWASP API Top 10, ASVS oder die eigene Richtlinie.
3. Automatisierter Scan. Einen Scanner gegen eine Testumgebung laufen lassen, um bekannte Fehlerklassen schnell abzudecken.
4. Manuelle Tests. Autorisierungsfehler brauchen echte Testkonten mit unterschiedlichen Rollen, damit der Auditor fragen kann: "Kommt Nutzer A an die Daten von Nutzer B?"
5. Bewertung. Jeden Befund nach Auswirkung und Ausnutzbarkeit einstufen und Verantwortliche zuweisen.
6. Beheben und erneut testen. Bestätigen, dass die Korrektur das Problem schließt und nichts anderes beschädigt.
7. Bericht. Befunde, Belege, Schweregrad und Maßnahmen, mit einer kurzen Zusammenfassung für Nicht-Techniker.

Was geprüft wird

• Authentifizierung: Token-Prüfung, Ablauf, Umgang mit Zugangsdaten, Schutz vor Brute Force.
• Autorisierung: Prüfungen auf Objekt-, Eigenschafts- und Funktionsebene an jedem Endpunkt, nicht nur am Login.
• Eingabeverarbeitung: Injection, Größenlimits für Anfragen, Schema-Validierung, serverseitige Anfragen aus Nutzereingaben.
• Ressourcenlimits: Rate Limits, Obergrenzen bei der Paginierung, teure Operationen.
• Datenpreisgabe: Felder, die der Aufrufer nicht sehen sollte, Tokens oder personenbezogene Daten in Logs, Fehlermeldungen mit internen Details.
• Konfiguration: Transportverschlüsselung, CORS, Debug-Modi, Standardzugangsdaten.
• Bestand und Drittanbieter: vergessene alte Versionen und der Umgang mit Daten aus anderen aufgerufenen APIs.

Häufige Fehler

• Nur dokumentierte Endpunkte prüfen. Alte Versionen und undokumentierte Routen sind der Ort der Überraschungen.
• Mit nur einem Admin-Konto testen. Autorisierungsfehler zeigen sich erst beim Identitätswechsel.
• Rate Limits nur am Gateway. Ist der Origin direkt erreichbar, bewirkt das Limit nichts.
• Ein einmaliges Audit. Die API ändert sich jeden Sprint, ein sauberer Bericht veraltet schnell.
• Scannen ohne Erlaubnis oder in Produktion. Holen Sie eine schriftliche Genehmigung ein und bevorzugen Sie eine Testumgebung. Siehe den Vergleich Penetrationstest-Tools.
• Kein erneuter Test. Ein Befund ist geschlossen, wenn er verifiziert ist, nicht wenn das Ticket zu ist.

Bezug zu Monitoring und Lasttests

LoadFocus ist kein Sicherheitsauditor und scannt nicht nach Schwachstellen. Es kann aber das Verhalten weiter beobachten, nachdem ein Audit etwas behoben hat. Das API-Monitoring führt geskriptete Prüfungen nach Zeitplan aus (im Free-Tarif alle 5 Minuten), von mehreren seiner 25 Regionen, und kann Statuscode, Body und Header prüfen. Eine Prüfung, die erwartet, dass eine Anfrage ohne Token abgewiesen wird, schlägt also fehl, wenn ein späteres Deployment sie öffnet. Mehrstufige Prüfungen können Anfragen verketten, etwa erst anmelden und dann einen weiteren Endpunkt aufrufen. Zum Thema Ressourcenverbrauch zeigt ein kostenloser API-Lasttest, wie sich ein öffentlicher Endpunkt unter Last verhält (nur GET-Anfragen, bis zu 25 virtuelle Nutzer von einem Standort); Lasttests sollten Sie nur gegen Systeme fahren, die Ihnen gehören oder für die Sie die Erlaubnis haben. Zur tieferen Suche im Live-Traffic siehe API Threat Hunting.

Häufige Fragen: API-Sicherheitsaudits

Wie oft sollte eine API auditiert werden?

Vor dem Start, nach größeren Änderungen an Authentifizierung oder Datenverarbeitung und danach regelmäßig. Weil sich APIs ständig ändern, ergänzen viele Teams zwischen den vollständigen Audits automatisierte Prüfungen, statt sich auf einen Bericht pro Jahr zu verlassen.

Was ist der Unterschied zwischen API-Sicherheitsaudit und Penetrationstest?

Die Begriffe überlappen. Ein Penetrationstest konzentriert sich darauf, Schwachstellen auszunutzen, und umfasst oft mehr als die API. Ein Audit prüft gegen einen benannten Standard und deckt neben der Ausnutzbarkeit auch Design, Konfiguration und Prozesse ab. Klären Sie vor dem Start, was jeweils enthalten ist.

Brauchen rein interne APIs ein Audit?

Ja. Interne APIs sind für jeden erreichbar, der im Netzwerk Fuß fasst oder einen Dienst kompromittiert, und verdienen dieselbe Authentifizierung, Autorisierung und Protokollierung wie öffentliche.

Was sollten wir für ein Audit vorbereiten?

Aktuelle API-Spezifikationen, eine Übersicht der Endpunkte und Versionen, Testkonten für jede Rolle, eine Testumgebung und eine Liste bekannter Probleme. Je vollständiger die Übersicht, desto weniger Zeit geht in die Erkundung.

Kann ein automatisierter Scanner ein Audit ersetzen?

Nein. Scanner decken bekannte Fehlerklassen schnell ab, wissen aber nicht, wem welches Objekt gehören sollte. Fehler wie Broken Object Level Authorization erfordern deshalb meist manuelle Tests mit mehreren Identitäten.