API-Security: Die OWASP API Top 10 und wie Wazuh sie sichtbar macht
Die OWASP API Top 10 erklärt, wo APIs angreifbar sind. Dieser Artikel zeigt, wie Wazuh diese Schwachstellen im Mittelstand sichtbar macht.
API-Security: Die OWASP API Top 10 und wie Wazuh sie sichtbar macht\n\n> Key Takeaways\n> - APIs sind heute das häufigste Angriffsziel in modernen IT-Infrastrukturen – auch im Mittelstand\n> - Die OWASP API Top 10 (2023) definiert die zehn kritischsten API-Schwachstellenkategorien\n> - Wazuh kann durch Custom Rules, Log-Analyse und Anomalieerkennung viele dieser Angriffsvektoren sichtbar machen\n> - NIS-2 und DSGVO verlangen nachweisbare Kontrollmechanismen – API-Monitoring ist kein Nice-to-have mehr\n\n## Warum API-Security im Mittelstand unterschätzt wird\n\nAPIs sind das Rückgrat moderner Unternehmens-IT. ERP-Systeme, CRM-Lösungen, Microsoft-365-Integrationen, Azure-Dienste – sie alle kommunizieren über Schnittstellen. Und genau dort setzen Angreifer an. Laut dem Verizon Data Breach Investigations Report 2024 sind Web-Anwendungen und APIs in über 60 % aller Datenpannen der primäre Einstiegspunkt.\n\nDas Problem im Mittelstand: Es gibt selten ein dediziertes Security-Team, das API-Traffic aktiv überwacht. Viele Unternehmen verlassen sich auf Perimeter-Schutz – Firewall, WAF – und gehen davon aus, dass ihr API-Gateway ausreichend absichert. Das greift zu kurz. Eine WAF erkennt Injection-Muster. Sie erkennt nicht, ob ein authentifizierter Nutzer auf die Datensätze anderer Nutzer zugreift.\n\nDie OWASP Foundation veröffentlicht seit 2019 eine eigene Liste der kritischsten API-Schwachstellen – getrennt von der bekannteren OWASP Top 10 für Webanwendungen. Die aktuelle Version von 2023 adressiert Schwachstellenklassen, die in klassischen Web-Scannern nicht erkennbar sind und in Penetrationstests regelmäßig die gravierendsten Befunde liefern.\n\n## Die OWASP API Top 10 (2023) im Überblick\n\n### API1:2023 – Broken Object Level Authorization (BOLA)\n\nBOLA ist die häufigste und in der Praxis gefährlichste API-Schwachstelle. Ein Angreifer ruft Ressourcen ab, auf die er keinen Zugriff haben dürfte – einfach durch Manipulation der Objekt-ID in der Anfrage.\n\nBeispiel: Ein Nutzer mit der ID 1042 fragt GET /api/orders/9987 ab – eine Bestellung eines anderen Kunden. Fehlt serverseitige Autorisierungsprüfung, liefert die API die Daten ohne Fehler zurück. HTTP-Statuscode 200, kein Alarm, kein Log-Eintrag mit Auffälligkeitsmarkierung.\n\nWazuh-Erkennung: Wazuh wertet HTTP-Logs aus nginx, Apache oder Azure API Management aus. Das Muster: viele GET-Anfragen mit inkrementell veränderten IDs von einer einzigen Quell-IP innerhalb kurzer Zeit.\n\n```xml\n<rule id=\
Frequently asked
Wie erkenne ich, ob meine API einen BOLA-Angriff erlebt?
BOLA-Angriffe (Broken Object Level Authorization) zeigen sich typischerweise als ungewöhnlich viele GET-Anfragen von einer einzigen IP-Adresse, bei denen die Objekt-ID in der URL systematisch inkrementiert wird – also z.B. /api/orders/1001, /api/orders/1002, /api/orders/1003 in kurzer Folge. In Wazuh lässt sich das mit Threshold-Regeln auf den Access-Logs Ihres API-Gateways (nginx, Azure API Management) erkennen. Ein weiteres Indiz: der HTTP-Statuscode bleibt dabei meist 200, da die API die Anfragen mangels Autorisierungsprüfung einfach beantwortet.
Reicht eine Web Application Firewall (WAF) als Schutz gegen die OWASP API Top 10?
Nein. Eine WAF schützt gut gegen bekannte Injection-Muster (SQLi, XSS, SSRF) und kann Rate-Limits durchsetzen. Die häufigsten API-Schwachstellen – BOLA, Broken Authentication, Broken Object Property Level Authorization – sind jedoch logische Fehler in der Autorisierungsschicht und erzeugen valide HTTP-Anfragen, die eine WAF nicht als Angriff erkennt. Hier brauchen Sie applikationsnahes Logging, Verhaltensanalyse und Korrelationsregeln, wie Wazuh sie bietet. WAF und SIEM ergänzen sich, ersetzen sich aber nicht.
Ab welcher Unternehmensgröße lohnt sich Wazuh-basiertes API-Monitoring?
Sobald Sie APIs betreiben, die Kundendaten oder Geschäftsdaten exponieren – unabhängig von der Unternehmensgröße. Praktisch bedeutet das: Jedes Unternehmen mit einer M365-Integration, einem ERP-Webservice oder einer eigenen Webanwendung hat APIs, die überwacht werden sollten. Wazuh ist Open Source und skaliert von wenigen Agenten für ein 20-Personen-Unternehmen bis zu Enterprise-Umgebungen. Der Hauptaufwand liegt nicht in der Infrastruktur, sondern in der initialen Regelkonfiguration und dem laufenden Tuning der Alerts.