Die größten API-Sicherheitsrisiken

Was sind die größten API-Sicherheitsrisiken?

Die größten API-Sicherheitsrisiken sind die Schwachstellen, die Angreifer am häufigsten ausnutzen, um fremde Daten zu lesen, Konten zu übernehmen oder einen Dienst lahmzulegen. Die maßgebliche Liste ist die OWASP API Security Top 10, zuletzt für 2023 veröffentlicht. Sie nennt zehn Kategorien, meist fehlende serverseitige Prüfungen: Wer darf welches Objekt, welches Feld und welche Funktion nutzen, und wie viel darf er verbrauchen. Zu jedem Risiko findest du unten eine kurze Erklärung und die übliche Lösung.

Die OWASP API Security Top 10 (2023)

API1:2023 Broken Object Level Authorization

Die API übernimmt eine Objekt-ID vom Client (zum Beispiel /orders/1043) und liefert den Datensatz, ohne zu prüfen, ob der Aufrufer ihn sehen darf. Lösung: Besitz bei jedem Objektzugriff serverseitig prüfen und unvorhersehbare IDs nur als zusätzliche Schicht nutzen, nicht als Ersatz.

API2:2023 Broken Authentication

Login, Token- oder Schlüsselbehandlung ist schwach: kein Limit für Login-Versuche, Tokens ohne Ablauf, Geheimnisse in URLs oder akzeptierte unsignierte Tokens. Lösung: kurzlebige Tokens, sorgfältige Prüfung von Signatur und Ablauf, Limits für Anmeldeversuche.

API3:2023 Broken Object Property Level Authorization

Der Aufrufer darf ein Objekt sehen oder ändern, aber nicht jedes Feld darin: Antworten verraten zu viel (Excessive Data Exposure) oder die API lässt Clients Felder wie role oder price schreiben (Mass Assignment). Lösung: explizite Feld-Allowlists für Antworten und Eingaben.

API4:2023 Unrestricted Resource Consumption

Anfragen verbrauchen CPU, Speicher, Bandbreite oder kostenpflichtige Drittanbieter-Aufrufe ohne Obergrenze, sodass ein Client den Dienst beeinträchtigen oder die Rechnung hochtreiben kann. Lösung: Rate Limits, Obergrenzen für Payload und Seitengröße, Timeouts und Kontingente pro Client. Genau dieses Risiko deckt ein Lasttest auf.

API5:2023 Broken Function Level Authorization

Normale Nutzer können administrative oder andere privilegierte Funktionen aufrufen, etwa indem sie GET durch DELETE ersetzen oder einen /admin-Pfad erraten. Lösung: standardmäßig verweigern und die Rolle des Aufrufers bei jeder Funktion prüfen, nicht nur in der Oberfläche.

API6:2023 Unrestricted Access to Sensitive Business Flows

Ein legitimer Ablauf, etwa der Kauf knapper Ware, das Posten von Kommentaren oder das Einlösen eines Gutscheins, lässt sich in einem Umfang automatisieren, der dem Geschäft schadet. Lösung: Automatisierung erkennen, sensible Abläufe mit Hürden versehen und nach Gerät, Konto und Geschäftsregel begrenzen. Siehe API-Missbrauch.

API7:2023 Server Side Request Forgery

Die API ruft eine vom Client gelieferte URL ab, sodass ein Angreifer den Server interne Dienste oder Metadaten-Endpunkte der Cloud aufrufen lassen kann. Lösung: Ziele per Allowlist festlegen, private Adressbereiche sperren und abgerufene Antworten nie ungefiltert zurückgeben.

API8:2023 Security Misconfiguration

Standardwerte und Konfigurationsdrift: ausführliche Fehlermeldungen, fehlendes TLS, zu offenes CORS, unnötige HTTP-Methoden, ungepatchte Komponenten. Lösung: eine gehärtete, wiederholbare Basis, im Code geprüft, und eine Kontrolle, dass die Produktion ihr entspricht.

API9:2023 Improper Inventory Management

Alte Versionen, Testhosts und undokumentierte Endpunkte bleiben erreichbar und ungepatcht. Lösung: ein aktuelles Inventar aus Hosts, Versionen und Verantwortlichen führen und abschalten, was niemandem gehört. Siehe API Sprawl.

API10:2023 Unsafe Consumption of APIs

Dein Dienst vertraut Daten von Drittanbieter-APIs mehr als Nutzereingaben, sodass ein kompromittierter oder fehlerhafter Partner schlechte Daten einschleusen oder Verkehr umleiten kann. Lösung: Antworten Dritter validieren und in ihrer Wirkung begrenzen, TLS und Timeouts erzwingen und sie als nicht vertrauenswürdige Eingabe behandeln.

So nutzt du die Liste

Beginne mit API1, API2 und API5: Fehler bei Autorisierung und Authentifizierung verursachen die schlimmsten Lecks, und ein Scanner tut sich damit schwer, weil jede Anfrage gültig aussieht. Teste sie mit zwei Konten: Melde dich als Nutzer A an und fordere Objekte von Nutzer B an, dann wiederhole es ohne Token. Ordne danach die übrigen Punkte deinem Stack zu. Die Disziplin insgesamt behandelt API-Sicherheit, die Techniken der Angreifer API-Angriffe.

Häufige Fehler

• Autorisierung nur in der Oberfläche prüfen. Die API wird direkt aufgerufen, also muss jede Prüfung auf dem Server liegen.
• Die Liste einmal abhaken. Neue Endpunkte und Versionen bringen dieselben Risiken zurück.
• IDs als Geheimnis betrachten. Eine schwer zu erratende ID ist keine Autorisierung.
• Zugangsdaten preisgeben. Tokens in URLs und Logs landen in falschen Händen. Siehe Bearer Token.
• Limits ignorieren. Ohne Rate Limit, Seitengrößen-Obergrenze oder Timeout ist API4 offen.

Wo Monitoring und Tests helfen

LoadFocus ist kein Schwachstellenscanner und findet weder Injection-Lücken noch Autorisierungsfehler. Einige dieser Kontrollen kann es dennoch unterstützen. Das API-Monitoring sendet geplante HTTP-Checks und prüft Statuscode, Header und Antwortinhalt, sodass du alarmiert wirst, wenn ein Endpunkt, der ohne Token 401 oder 403 liefern soll, plötzlich 200 liefert, oder wenn eine abgeschaltete alte Version wieder auftaucht. Lasttests zeigen, wie sich ein Endpunkt unter vielen gleichzeitigen Anfragen verhält, und damit, ob die Limits hinter API4 tatsächlich greifen. Tipps zu Werkzeugen findest du in unserer Übersicht API-Monitoring-Tools (auf Englisch). Für Penetrationstests und Schwachstellenscans nutze einen spezialisierten Sicherheitstester.

Häufige Fragen

Was ist das größte API-Sicherheitsrisiko?

In der OWASP API Security Top 10 für 2023 steht Broken Object Level Authorization (BOLA) an erster Stelle. Es entsteht, wenn eine API ein Objekt anhand seiner ID liefert, ohne zu prüfen, ob der Aufrufer darauf zugreifen darf.

Wie unterscheidet sich die API Top 10 von der Top 10 für Webanwendungen?

Die Liste für Webanwendungen behandelt Probleme im Browserbereich wie Injection und Cross-Site-Scripting. Die API-Liste konzentriert sich darauf, wie APIs Objekte, Eigenschaften und Geschäftsabläufe direkt bereitstellen, weshalb Autorisierung und Ressourcenlimits deutlich höher stehen.

Wie oft wird die OWASP API Security Top 10 aktualisiert?

Die aktuelle Ausgabe stammt von 2023, die vorherige von 2019. Prüfe auf der OWASP-Seite die neueste Version, bevor du ein Review darauf aufbaust.

Kann ein Lasttest API-Sicherheitsprobleme finden?

Nicht direkt. Ein Lasttest zeigt, wie sich eine API unter hohem Traffic verhält, und hilft, Rate Limits und Ressourcengrenzen zu bestätigen. Autorisierungs- oder Injection-Lücken erkennt er nicht, du brauchst also weiterhin Sicherheitstests.