API-Security: Die unterschaetzte Angriffsflaeche moderner Unternehmen

APIs sind das Rueckgrat moderner Softwarearchitekturen — und zugleich der am schnellsten wachsende Angriffsvektor. 2024 gehen bereits 40 Prozent aller Web-Angriffe ueber APIs. Die meisten Unternehmen schuetzen ihre APIs nicht annaehernd so rigoros wie ihre Webanwendungen.

Das Wichtigste in Kuerze

Angriffsflaeche: APIs machen 83% des gesamten Web-Traffics aus — und werden 3x haeufiger angegriffen als klassische Webanwendungen.
Hauptrisiko: Broken Object Level Authorization (BOLA) ist die haeufigste API-Schwachstelle und ermoeglicht Zugriff auf fremde Datensaetze.
Dunkelziffer: Das durchschnittliche Unternehmen hat 30% mehr APIs exponiert als dokumentiert — Shadow APIs sind ein massives Sicherheitsrisiko.
Schutz: API Gateway + Runtime Protection + Shift-Left-Testing bilden die drei Verteidigungslinien.
Standard: Die OWASP API Security Top 10 (2023) sind der verbindliche Referenzrahmen fuer API-Absicherung.

Warum APIs das neue Einfallstor sind

Jede moderne Anwendung kommuniziert ueber APIs — mit anderen Anwendungen, mit Cloud-Diensten, mit Partnern und mit mobilen Apps. Akamai berichtet, dass APIs 83 Prozent des gesamten Web-Traffics ausmachen. Gleichzeitig sind APIs oft weniger geschuetzt als die Anwendungen, die sie bedienen.

Der Grund: Webanwendungen werden seit 20 Jahren mit WAFs, Content-Security-Policies und Browser-Sicherheitsfeatures geschuetzt. APIs haben oft keinen vergleichbaren Schutz. Sie sind direkte Schnittstellen zu Geschaeftslogik und Datenbanken — und damit das attraktivste Ziel fuer Angreifer.

Prominente Vorfaelle belegen das Risiko: Optus (Australiens zweitgroesster Telko) verlor 2022 die Daten von 10 Millionen Kunden ueber eine ungeschuetzte API. T-Mobile US wurde 2023 ueber eine API-Schwachstelle kompromittiert — 37 Millionen Kundendaten betroffen.

OWASP API Security Top 10

Die OWASP API Security Top 10 (2023 aktualisiert) definieren die kritischsten Risiken:

1. Broken Object Level Authorization (BOLA): Die API prueft nicht, ob der aufrufende User auf das angeforderte Objekt zugreifen darf. Ein Angreifer aendert die ID im Request und erhaelt Zugriff auf fremde Daten. Haeufigste Schwachstelle, trivial auszunutzen.

2. Broken Authentication: Schwache oder fehlende Authentifizierungsmechanismen. API-Keys ohne Rotation, fehlende Rate Limits, keine Token-Validierung.

3. Broken Object Property Level Authorization: Die API gibt mehr Datenfelder zurueck als der User sehen darf. Mass Assignment: Der User kann Felder aendern, die nicht fuer ihn bestimmt sind.

4. Unrestricted Resource Consumption: Keine Limits fuer API-Aufrufe, Datenmengen oder Compute-Ressourcen. Ermoeglichen DoS-Angriffe und teure Cloud-Rechnungen.

Drei Verteidigungslinien

Linie 1: API Gateway. Zentraler Eingangspunkt fuer alle API-Aufrufe. Authentifizierung, Rate Limiting, Request-Validierung und TLS-Terminierung. Tools: Kong, Apigee, AWS API Gateway, Azure API Management.

Linie 2: Runtime Protection. Echtzeit-Ueberwachung des API-Traffics auf Anomalien, BOLA-Versuche und ungewoehnliche Datenzugriffsmuster. Spezialisierte Tools wie Salt Security, Noname Security oder 42Crunch analysieren API-Verhalten und erkennen Angriffe, die regelbasierte Systeme uebersehen.

Linie 3: Shift-Left-Testing. API-Security-Tests in die Entwicklungspipeline integrieren. OpenAPI-Spec-Validierung, SAST fuer API-Code, automatisierte DAST-Scans gegen Staging-Umgebungen. Je frueher Schwachstellen gefunden werden, desto guenstiger die Behebung.

Shadow APIs: Das unsichtbare Risiko

Salt Security berichtet, dass das durchschnittliche Unternehmen 30 Prozent mehr APIs exponiert hat als dokumentiert. Diese Shadow APIs entstehen durch vergessene Testumgebungen, deprecated Endpunkte die nie abgeschaltet wurden und interne APIs die versehentlich oeffentlich erreichbar sind.

Shadow APIs sind besonders gefaehrlich, weil sie keiner Governance unterliegen: keine Authentifizierung, kein Monitoring, kein Patching. Der erste Schritt jeder API-Security-Initiative ist deshalb ein vollstaendiges API-Inventar — automatisiert durch Traffic-Analyse, nicht manuell durch Befragung der Entwickler.

Key Facts auf einen Blick

API-Angriffsanteil: 40% aller Web-Angriffe (Akamai, 2024)

API-Traffic-Anteil: 83% des gesamten Web-Traffics (Akamai)

Haeufigste Schwachstelle: BOLA — in 68% aller API-Penetrationstests gefunden (Salt Security)

Shadow APIs: 30% mehr exponierte APIs als dokumentiert (Durchschnitt)

Quelle: OWASP, Akamai, Salt Security, Gartner, 2023/24

Haeufige Fragen

Was ist der Unterschied zwischen API-Security und Web-Security?

Web-Security schuetzt die Benutzeroberflaeche, API-Security schuetzt die Programmierschnittstellen dahinter. APIs exponieren Geschaeftslogik und Daten direkter als Webanwendungen und erfordern spezifische Schutzmassnahmen wie BOLA-Erkennung und Schema-Validierung.

Reicht ein API Gateway fuer API-Security?

Nein. Ein API Gateway bietet Basis-Schutz durch Authentifizierung und Rate Limiting. Fuer Angriffe auf Geschaeftslogik-Ebene (BOLA, Mass Assignment) braucht es spezialisierte Runtime Protection.

Wie finde ich Shadow APIs?

Durch Traffic-Analyse am Netzwerk-Perimeter. Tools wie Salt Security oder Noname Security identifizieren APIs automatisch durch Analyse des HTTP-Traffics. Ergaenzend: Cloud-Log-Analyse und regelmäßige externe Scans.

Was kostet API-Security?

API Gateway: ab 500 Euro monatlich. Runtime Protection: 2.000-10.000 Euro monatlich je nach API-Volumen. Shift-Left-Tools: oft Open Source oder ab 200 Euro monatlich. Der ROI zeigt sich im ersten verhinderten Datenleck.

Sind GraphQL-APIs sicherer als REST?

Nicht per se. GraphQL hat eigene Risiken: Introspection-Leaks, Query-Depth-Angriffe und Batching-Missbrauch. Die Sicherheitsprinzipien sind dieselben, die Implementierung unterscheidet sich.