Top API Sicherheitsrisiken

Was sind die groessten API-Sicherheitsrisiken?

Die groessten API-Sicherheitsrisiken sind die Schwachstellenkategorien, die Angreifer am zuverlaessigsten ausnutzen, um Daten zu stehlen, Konten zu uebernehmen oder einen Dienst lahmzulegen. Moderne Anwendungen legen Geschaeftslogik direkt ueber APIs offen, sodass ein einziger fehlerhafter Autorisierungscheck einen ganzen Datenbestand preisgeben kann. Diese Seite zaehlt die wichtigsten Risiken auf, angelehnt an die anerkannten Kategorien der OWASP API Security Top 10, und erklaert je Risiko, was es ist, warum es gefaehrlich ist und wie man es entschaerft. Zur Disziplin insgesamt siehe Was ist API-Sicherheit, zu den Angriffstechniken siehe Was sind API-Angriffe.

Autorisierungsrisiken

Autorisierungsfehler sind die schaedlichsten API-Risiken, da sie einem Nutzer den Zugriff auf die Daten oder privilegierten Funktionen eines anderen ermoeglichen. Automatische Scanner uebersehen sie oft, weil die Anfrage selbst voellig gueltig 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 Eigentuemerschaft zu pruefen. Das Aendern der ID gibt fremde Daten zurueck.

• Warum es gefaehrlich ist: BOLA ist die haeufigste schwere API-Schwachstelle und laesst sich durch simples Durchzaehlen von IDs beliebig skalieren.
• Wie man es entschaerft: Erzwingen Sie bei jedem Objektzugriff eine Eigentumspruefung und begrenzen Sie jede Abfrage auf den authentifizierten Nutzer oder das Team. Bevorzugen Sie zufaellige, 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 pruefen.

• Warum es gefaehrlich ist: Ein normaler Nutzer kann Funktionen aufrufen, die Administratoren vorbehalten sind, etwa das Loeschen von Datensaetzen.
• Wie man es entschaerft: Standardmaessig verweigern. Erzwingen Sie Rollenpruefungen zentral in einer Middleware und verlassen Sie sich nie darauf, dass der Client eine Schaltflaeche verbirgt.

Broken Object Property Level Authorization

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

• Warum es gefaehrlich ist: Excessive Data Exposure gibt personenbezogene Daten preis; Mass Assignment erlaubt eine Rechteausweitung durch ein zusaetzliches Feld im Anfragekoerper.
• Wie man es entschaerft: Geben Sie nur die noetigen Eigenschaften ueber explizite Response-Schemas zurueck und binden Sie beschreibbare Felder ueber eine strikte Allowlist.

Authentifizierungsrisiken

Broken Authentication

Was es ist: Schwaechen bei der Identitaetspruefung, etwa nicht limitiertes Credential Stuffing, fehlende Token-Validierung, nicht ablaufende Tokens oder Geheimnisse in URLs.

• Warum es gefaehrlich ist: Ist die Authentifizierung umgangen, sind alle nachgelagerten Kontrollen wirkungslos; der Angreifer wird zum legitimen Nutzer.
• Wie man es entschaerft: Nutzen Sie gepruefte Bibliotheken, validieren Sie Signatur und Ablauf jedes Tokens und begrenzen Sie Login- und Token-Endpunkte per Rate Limiting.

Ressourcen- und Verfuegbarkeitsrisiken

Unrestricted Resource Consumption

Was es ist: Die API begrenzt den Ressourcenverbrauch eines Aufrufers nicht: kein Rate Limiting, keine Groessenbegrenzung, keine Paginierung, keine Obergrenze fuer teure nachgelagerte Aufrufe.

• Warum es gefaehrlich ist: Angreifer koennen Denial of Service ausloesen oder hohe Infrastruktur- und Drittanbieterkosten verursachen.
• Wie man es entschaerft: Setzen Sie Rate Limiting und Kontingente pro Client, begrenzen Sie Nutzlast und Arraylaengen 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 bestaetigen, dass Rate Limits und Autoscaling greifen; LoadFocus API-Monitoring beobachtet Latenz und Fehlerraten kontinuierlich.

Unrestricted Access to Sensitive Business Flows

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

• Warum es gefaehrlich ist: Automatisierung kann Bestaende aufkaufen oder Systeme manipulieren, ohne je eine technische Kontrolle zu brechen.
• Wie man es entschaerft: Identifizieren Sie sensible Ablaeufe im Design und ergaenzen 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 pruefen, sodass der Server interne Systeme oder Cloud-Metadaten-Endpunkte anfragt.

• Warum es gefaehrlich ist: SSRF erreicht interne Dienste hinter der Firewall und kann in der Cloud Instanz-Zugangsdaten abgreifen.
• Wie man es entschaerft: 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, ausfuehrliche Fehlermeldungen, fehlende Security-Header, zu freizuegiges CORS oder in Produktion aktivierte Debug-Funktionen.

• Warum es gefaehrlich ist: Fehlkonfiguration liefert Angreifern ohne raffinierten Exploit Informationen und Angriffspunkte.
• Wie man es entschaerft: Haerten Sie die Konfiguration ueber einen automatisierten, wiederholbaren Prozess, deaktivieren Sie ungenutzte Funktionen und halten Sie Abhaengigkeiten 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 gefaehrlich ist: Ein veralteter Endpunkt hat oft nicht die Korrekturen der aktuellen Version und bietet eine ungeschuetzte Tuer.
• Wie man es entschaerft: Fuehren Sie ein aktuelles Inventar jeder API, jedes Hosts und jeder Version, nehmen Sie alte Versionen planmaessig ausser Betrieb.

Unsafe Consumption of APIs

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

• Warum es gefaehrlich ist: Ein kompromittierter Upstream kann Nutzdaten einschleusen, die ungeprueft in Ihren Datenbestand fliessen.
• Wie man es entschaerft: Validieren Sie Drittdaten genau wie Nutzereingaben, nutzen Sie verschluesselte Kanaele und bewerten Sie die Sicherheitslage der Partner.

Wie man diese Risiken priorisiert und entschaerft

Beheben Sie zuerst die Autorisierung, da BOLA und Fehler auf Funktionsebene die groessten Vorfaelle verursachen, und arbeiten Sie dann nach aussen zu Authentifizierung, Ressourcenlimits und Konfiguration.

• Standardmaessig verweigern: Jeder Objekt- und Funktionszugriff ist unautorisiert, bis eine explizite Pruefung 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 Nichtunterstuetztes abschalten.
• Kontinuierlich testen und ueberwachen: Verbrauchsschutz unter realer Last pruefen und Produktion beobachten.

Risiko	Typische Ursache	Gegenmassnahme
Broken Object Level Authorization (BOLA)	Keine Eigentumspruefung der Objekt-ID	Jede Abfrage auf den Nutzer begrenzen
Broken Function Level Authorization	Fehlende Rollenpruefung	Zentrales Deny-by-default
Broken Object Property Level Authorization	Ganzobjekt-Bindung, ungefilterte Antworten	Explizite Schemas und Write-Allowlists
Broken Authentication	Schwache Token-Handhabung	Gepruefte Bibliotheken und Rate Limits
Unrestricted Resource Consumption	Keine Limits oder Groessengrenzen	Kontingente, Paginierung, Load Testing
Unrestricted Access to Business Flows	Kein Anti-Automatismus	Drosselung und Human-Verification
Server-Side Request Forgery (SSRF)	Ungepruefte Client-URLs	URL-Allowlists, interne Bereiche sperren
Security Misconfiguration	Unsichere Voreinstellungen	Gehaertete, automatisierte Konfiguration
Improper Inventory Management	Vergessene alte Versionen	Live-Inventar und Versionsstilllegung
Unsafe Consumption of APIs	Blindes Vertrauen in Upstream	Drittdaten wie Nutzereingaben pruefen

FAQ zu API-Sicherheitsrisiken

Was ist das kritischste API-Sicherheitsrisiko?

Broken Object Level Authorization (BOLA) gilt durchgehend als kritischstes Risiko, da es haeufig ist, sich durch Aendern einer Objekt-ID leicht ausnutzen laesst und einen ganzen Datenbestand preisgeben kann. Eine Eigentumspruefung pro Objekt ist die wirksamste Verteidigung.

Wie haengen 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 Datensaetze durch Aendern 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 Pruefungen.

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 bestaetigen, dass diese Schutzmechanismen unter Last greifen. LoadFocus bietet Cloud-Load-Testing und kontinuierliches API-Monitoring genau dafuer.

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 gueltig ist. Kombinieren Sie es mit strikter Autorisierung, Eingabevalidierung und Anti-Automatismus.

Wie oft sollten wir unsere API-Sicherheitsrisiken pruefen?

Behandeln Sie es als kontinuierlich statt periodisch. Pruefen Sie Autorisierung und Validierung bei jedem neuen Endpunkt, halten Sie ein aktuelles API-Inventar, patchen Sie zeitnah und ueberwachen Sie den Produktionsverkehr, damit Missbrauch frueh auffaellt.