APIs sind das Rückgrat moderner Software und damit ein zentrales Angriffsziel. Drei Befunde aus aktuellen Primärquellen fassen das Problem zusammen: Vorfälle sind weit verbreitet, Angreifer folgen gezielt den bekannten API-Schwachstellen, und ein Datenleck bleibt teuer.

99%
der Organisationen hatten im letzten Jahr Sicherheitsprobleme mit APIs
Salt Security, 2025
32%
erlebten einen konkreten API-Sicherheitsvorfall
Salt Security, 2026
78%
der Angriffsversuche nutzen OWASP-API-Top-10-Methoden
Salt Security, 2026
4,4 Mio.
USD kostet ein Datenleck im weltweiten Schnitt
IBM, 2025

Warum ein gültiger Login nicht reicht

Das häufigste API-Risiko ist Broken Object Level Authorization (BOLA): Die API prüft nicht, ob ein eingeloggter Nutzer auf genau dieses Objekt zugreifen darf. Es braucht keinen Exploit, nur eine hochgezählte ID. Das passt zum Befund, dass laut Salt Labs nahezu alle analysierten Angriffsversuche aus authentifizierten Quellen stammen, der Angreifer ist also eingeloggt.

Login als Nutzer Agültige Anmeldungerlaubt
GET /rechnungen/1001eigene Rechnung200 OK
GET /rechnungen/1002fremde Rechnung200 OK · BOLA

Broken Object Level Authorization: derselbe gültige Login, eine hochgezählte ID, fremde Daten. Klassische Login- und Perimeter-Schranken greifen hier nicht.

Die Angriffsfläche wächst mit

Je mehr Geschäftslogik über APIs läuft, desto mehr verschiebt sich auch das Angriffsgeschehen dorthin. Schon Ende 2021 machten API-Aufrufe laut Cloudflare 54% des gesamten Request-Volumens aus und wuchsen rund doppelt so schnell wie klassischer Web-Traffic. 66% der Organisationen berichten, dass ihre Zahl an APIs im letzten Jahr um über 50% gewachsen ist.

Und der Trend beschleunigt sich durch KI-gestützte Entwicklung: Werkzeuge wie Copilot oder Cursor und zunehmend autonome KI-Agenten erzeugen Code, und damit Endpunkte, schneller, als Reviews und Governance hinterherkommen. So entstehen vermehrt undokumentierte oder nie geprüfte Routen (Phantom- und Schatten-APIs), und KI-Agenten samt ihren Tool-Schnittstellen bilden eine ganz neue API-Angriffsfläche. Wie man trotzdem den Überblick behält, steht unter API Security sicherstellen.

Autorisierungsfehler dominieren

Drei der fünf höchsten OWASP-API-Risiken sind reine Berechtigungsfehler: API1 (BOLA), API3 (BOPLA) und API5 (BFLA). Sie lassen sich nicht an einer Signatur erkennen, sondern nur, indem man die Logik tatsächlich durchspielt. Genau das macht sie so gefährlich und zugleich so schwer für klassische Scanner.

Kernbotschaft

API-Angriffe laufen meist über gültige Logins und fehlende Berechtigungsprüfungen, nicht über klassische Exploits. Wer APIs absichern will, muss die Logik testen, nicht nur Muster scannen.

Warum diese Lücken so gefährlich sind

Das eigentlich Beunruhigende ist nicht die schiere Zahl der API-Lücken, sondern wie trivial sie sich ausnutzen lassen, oft ohne Spezialwissen und ohne gültiges Konto.

97%
der API-Schwachstellen sind mit einer einzigen Anfrage ausnutzbar
Wallarm, 2026
59%
erfordern dafür nicht einmal eine Authentifizierung
Wallarm, 2026
17%
aller gemeldeten Schwachstellen entfallen inzwischen auf APIs
Wallarm, 2026
+44%
mehr Ausnutzung öffentlich erreichbarer Anwendungen im Jahresvergleich
IBM X-Force, 2026

Was das konkret heißt: Es braucht keinen ausgefeilten Exploit. Eine einzige, völlig normal aussehende Anfrage mit einer hochgezählten ID, also eine BOLA-Lücke wie GET /orders/124 statt der eigenen 123, genügt, um fremde Datensätze abzugreifen. Kein Schadcode, oft kein Login, und für ein Pattern-basiertes Schutzsystem sieht die Anfrage völlig legitim aus.

Die Verteidigung hinkt hinterher: Während APIs zur dominanten Angriffsfläche werden, trauen sich laut Salt nur 18% der Organisationen zu, KI-gestützte Angriffe überhaupt zu erkennen (H1 2026). Wer den eigenen API-Bestand und die Berechtigungslogik nicht kontinuierlich prüft, bemerkt einen Vorfall oft erst, wenn er in der Zeitung steht.

Häufige Fragen

Warum erkennt ein klassischer Scanner BOLA nicht?

Weil ein BOLA-Request technisch völlig legitim ist und nur die manipulierte Objekt-ID den Missbrauch verrät. Ein signatur- oder musterbasierter Scanner sieht kein verdächtiges Muster. Ob der Zugriff erlaubt ist, weiß nur die Anwendungslogik im Kontext des Nutzers.

Reicht ein jährlicher Pentest oder eine WAF?

Nein. APIs ändern sich mit jedem Deploy, und ein Befund von vor zwölf Monaten sagt nichts über den heutigen Stand. Eine WAF filtert Muster, keine Logikfehler. Wirksam ist kontinuierliches, logikbasiertes Testen.

Vergrößert KI die Angriffsfläche?

Ja. KI-Codegeneratoren erzeugen schneller mehr Endpunkte, als die Governance erfassen kann, inklusive nie geplanter Phantom-Routen. Das erhöht die Zahl ungeprüfter Schnittstellen.

Quellen

Weiterlesen