Top API Sicherheitsrisiken

Was sind die größten API-Sicherheitsrisiken?

Die größten API-Sicherheitsrisiken sind die Schwachstellenkategorien, die Angreifer am zuverlässigsten ausnutzen, um Daten zu stehlen, Konten zu übernehmen oder einen Dienst lahmzulegen. Moderne Anwendungen legen Geschäftslogik direkt über APIs offen, sodass ein einziger fehlerhafter Autorisierungscheck einen ganzen Datenbestand preisgeben kann. Diese Seite zählt die wichtigsten Risiken auf, angelehnt an die anerkannten Kategorien der OWASP API Security Top 10, und erklärt je Risiko, was es ist, warum es gefährlich ist und wie man es entschärft. Zur Disziplin insgesamt siehe Was ist API-Sicherheit, zu den Angriffstechniken siehe Was sind API-Angriffe.

Autorisierungsrisiken

Autorisierungsfehler sind die schädlichsten API-Risiken, da sie einem Nutzer den Zugriff auf die Daten oder privilegierten Funktionen eines anderen ermöglichen. Automatische Scanner übersehen sie oft, weil die Anfrage selbst völlig gültig aussieht.

Broken Object Level Authorization (BOLA)

Was es ist: Die API akzeptiert eine Objekt-ID (etwa /orders/1043) vom Client und liefert den Datensatz, ohne die Eigentümerschaft zu prüfen. Das Ändern der ID gibt fremde Daten zurück.

• Warum es gefährlich ist: BOLA ist die häufigste schwere API-Schwachstelle und lässt sich durch simples Durchzählen von IDs beliebig skalieren.
• Wie man es entschärft: Erzwingen Sie bei jedem Objektzugriff eine Eigentumsprüfung und begrenzen Sie jede Abfrage auf den authentifizierten Nutzer oder das Team. Bevorzugen Sie zufällige, nicht fortlaufende Identifikatoren.

Broken Function Level Authorization

Was es ist: Die API stellt privilegierte Operationen (eine andere HTTP-Methode, eine /admin-Route) bereit, ohne die Rolle des Aufrufers zu prüfen.

• Warum es gefährlich ist: Ein normaler Nutzer kann Funktionen aufrufen, die Administratoren vorbehalten sind, etwa das Löschen von Datensätzen.
• Wie man es entschärft: Standardmäßig verweigern. Erzwingen Sie Rollenprüfungen zentral in einer Middleware und verlassen Sie sich nie darauf, dass der Client eine Schaltfläche verbirgt.

Broken Object Property Level Authorization

Was es ist: Die API liefert oder akzeptiert einzelne Eigenschaften, die der Aufrufer nicht sehen oder ändern sollte. Dies vereint Excessive Data Exposure (die Antwort enthält sensible Felder) und Mass Assignment (die API bindet Client-Eingaben an interne Felder wie role ohne Allowlist).

• Warum es gefährlich ist: Excessive Data Exposure gibt personenbezogene Daten preis; Mass Assignment erlaubt eine Rechteausweitung durch ein zusätzliches Feld im Anfragekörper.
• Wie man es entschärft: Geben Sie nur die nötigen Eigenschaften über explizite Response-Schemas zurück und binden Sie beschreibbare Felder über eine strikte Allowlist.

Authentifizierungsrisiken

Broken Authentication

Was es ist: Schwächen bei der Identitätsprüfung, etwa nicht limitiertes Credential Stuffing, fehlende Token-Validierung, nicht ablaufende Tokens oder Geheimnisse in URLs.

• Warum es gefährlich ist: Ist die Authentifizierung umgangen, sind alle nachgelagerten Kontrollen wirkungslos; der Angreifer wird zum legitimen Nutzer.
• Wie man es entschärft: Nutzen Sie geprüfte Bibliotheken, validieren Sie Signatur und Ablauf jedes Tokens und begrenzen Sie Login- und Token-Endpunkte per Rate Limiting.

Ressourcen- und Verfügbarkeitsrisiken

Unrestricted Resource Consumption

Was es ist: Die API begrenzt den Ressourcenverbrauch eines Aufrufers nicht: kein Rate Limiting, keine Größenbegrenzung, keine Paginierung, keine Obergrenze für teure nachgelagerte Aufrufe.

• Warum es gefährlich ist: Angreifer können Denial of Service auslösen oder hohe Infrastruktur- und Drittanbieterkosten verursachen.
• Wie man es entschärft: Setzen Sie Rate Limiting und Kontingente pro Client, begrenzen Sie Nutzlast und Arraylängen und erzwingen Sie Paginierung. Diese Kontrolle sollten Sie unter realer Last testen. Mit LoadFocus Load Testing senden Sie kontrollierten, hochparallelen Verkehr gegen einen Endpunkt, um zu bestätigen, dass Rate Limits und Autoscaling greifen; LoadFocus API-Monitoring beobachtet Latenz und Fehlerraten kontinuierlich.

Unrestricted Access to Sensitive Business Flows

Was es ist: Ein Geschäftsablauf (Kauf eines limitierten Artikels, Kontoerstellung) ist ohne Schutz gegen massenhafte Automatisierung offen, obwohl jede einzelne Anfrage autorisiert ist.

• Warum es gefährlich ist: Automatisierung kann Bestände aufkaufen oder Systeme manipulieren, ohne je eine technische Kontrolle zu brechen.
• Wie man es entschärft: Identifizieren Sie sensible Abläufe im Design und ergänzen Sie Device Fingerprinting, Human-Verification und ablaufspezifische Drosselung.

Server- und Konfigurationsrisiken

Server-Side Request Forgery (SSRF)

Was es ist: Die API ruft eine vom Client gelieferte URL ab, ohne sie zu prüfen, sodass der Server interne Systeme oder Cloud-Metadaten-Endpunkte anfragt.

• Warum es gefährlich ist: SSRF erreicht interne Dienste hinter der Firewall und kann in der Cloud Instanz-Zugangsdaten abgreifen.
• Wie man es entschärft: Validieren und allowlisten Sie ausgehende URLs und Schemata, blockieren Sie interne Adressbereiche und deaktivieren Sie HTTP-Redirects bei serverseitigen Abrufen.

Security Misconfiguration

Was es ist: unsichere Voreinstellungen, ausführliche Fehlermeldungen, fehlende Security-Header, zu freizügiges CORS oder in Produktion aktivierte Debug-Funktionen.

• Warum es gefährlich ist: Fehlkonfiguration liefert Angreifern ohne raffinierten Exploit Informationen und Angriffspunkte.
• Wie man es entschärft: Härten Sie die Konfiguration über einen automatisierten, wiederholbaren Prozess, deaktivieren Sie ungenutzte Funktionen und halten Sie Abhängigkeiten gepatcht.

Inventar- und Lieferkettenrisiken

Improper Inventory Management

Was es ist: Die Organisation kennt nicht alle ihre APIs. Alte Versionen, exponierte Staging-Endpunkte und undokumentierte Shadow-APIs bleiben erreichbar.

• Warum es gefährlich ist: Ein veralteter Endpunkt hat oft nicht die Korrekturen der aktuellen Version und bietet eine ungeschützte Tür.
• Wie man es entschärft: Führen Sie ein aktuelles Inventar jeder API, jedes Hosts und jeder Version, nehmen Sie alte Versionen planmäßig außer Betrieb.

Unsafe Consumption of APIs

Was es ist: Die API vertraut Daten von Dritt- oder Upstream-APIs mehr als Nutzerdaten und überspringt deren Validierung.

• Warum es gefährlich ist: Ein kompromittierter Upstream kann Nutzdaten einschleusen, die ungeprüft in Ihren Datenbestand fließen.
• Wie man es entschärft: Validieren Sie Drittdaten genau wie Nutzereingaben, nutzen Sie verschlüsselte Kanäle und bewerten Sie die Sicherheitslage der Partner.

Wie man diese Risiken priorisiert und entschärft

Beheben Sie zuerst die Autorisierung, da BOLA und Fehler auf Funktionsebene die größten Vorfälle verursachen, und arbeiten Sie dann nach außen zu Authentifizierung, Ressourcenlimits und Konfiguration.

• Standardmäßig verweigern: Jeder Objekt- und Funktionszugriff ist unautorisiert, bis eine explizite Prüfung besteht.
• Alles an Vertrauensgrenzen validieren: IDs, Body-Felder, Drittantworten und ausgehende URLs.
• Jeden Endpunkt begrenzen: Rate Limits, Kontingente, Nutzlastgrenzen und Paginierung.
• Inventar pflegen: jede Version und jeden Host kennen und Nichtunterstütztes abschalten.
• Kontinuierlich testen und überwachen: Verbrauchsschutz unter realer Last prüfen und Produktion beobachten.

Risiko	Typische Ursache	Gegenmaßnahme
Broken Object Level Authorization (BOLA)	Keine Eigentumsprüfung der Objekt-ID	Jede Abfrage auf den Nutzer begrenzen
Broken Function Level Authorization	Fehlende Rollenprüfung	Zentrales Deny-by-default
Broken Object Property Level Authorization	Ganzobjekt-Bindung, ungefilterte Antworten	Explizite Schemas und Write-Allowlists
Broken Authentication	Schwache Token-Handhabung	Geprüfte Bibliotheken und Rate Limits
Unrestricted Resource Consumption	Keine Limits oder Größengrenzen	Kontingente, Paginierung, Load Testing
Unrestricted Access to Business Flows	Kein Anti-Automatismus	Drosselung und Human-Verification
Server-Side Request Forgery (SSRF)	Ungeprüfte Client-URLs	URL-Allowlists, interne Bereiche sperren
Security Misconfiguration	Unsichere Voreinstellungen	Gehärtete, automatisierte Konfiguration
Improper Inventory Management	Vergessene alte Versionen	Live-Inventar und Versionsstilllegung
Unsafe Consumption of APIs	Blindes Vertrauen in Upstream	Drittdaten wie Nutzereingaben prüfen

FAQ zu API-Sicherheitsrisiken

Was ist das kritischste API-Sicherheitsrisiko?

Broken Object Level Authorization (BOLA) gilt durchgehend als kritischstes Risiko, da es häufig ist, sich durch Ändern einer Objekt-ID leicht ausnutzen lässt und einen ganzen Datenbestand preisgeben kann. Eine Eigentumsprüfung pro Objekt ist die wirksamste Verteidigung.

Wie hängen diese Risiken mit den OWASP API Security Top 10 zusammen?

Die Risiken auf dieser Seite entsprechen direkt den Kategorien der OWASP API Security Top 10, die als Referenzliste der wichtigsten API-Schwachstellen gepflegt werden und Teams ein gemeinsames Vokabular geben.

Was ist der Unterschied zwischen BOLA und Broken Function Level Authorization?

BOLA betrifft Daten: Ein Nutzer erreicht fremde Datensätze durch Ändern einer ID. Broken Function Level Authorization betrifft Aktionen: Ein Nutzer ruft eine Operation auf, die seiner Rolle nicht erlaubt ist. Beide entstehen durch fehlende serverseitige Prüfungen.

Wie hilft Load Testing bei der API-Sicherheit?

Mehrere Risiken, besonders Unrestricted Resource Consumption, werden durch Rate Limits, Kontingente und Autoscaling verteidigt. Load Testing sendet kontrollierten, hochparallelen Verkehr, um zu bestätigen, dass diese Schutzmechanismen unter Last greifen. LoadFocus bietet Cloud-Load-Testing und kontinuierliches API-Monitoring genau dafür.

Reicht Rate Limiting, um API-Missbrauch zu stoppen?

Rate Limiting ist wichtig, aber nicht ausreichend. Es bremst Brute Force und Denial of Service, stoppt aber keine Autorisierungsfehler, SSRF oder Business-Flow-Missbrauch, bei dem jede Anfrage gültig ist. Kombinieren Sie es mit strikter Autorisierung, Eingabevalidierung und Anti-Automatismus.

Wie oft sollten wir unsere API-Sicherheitsrisiken prüfen?

Behandeln Sie es als kontinuierlich statt periodisch. Prüfen Sie Autorisierung und Validierung bei jedem neuen Endpunkt, halten Sie ein aktuelles API-Inventar, patchen Sie zeitnah und überwachen Sie den Produktionsverkehr, damit Missbrauch früh auffällt.