Zurück zum Blog
Home Blog API Security
API Security

OWASP API Security Top 10 2023: Die kritischsten API-Sicherheitsrisiken

APIs sind das Rückgrat moderner Anwendungen - und damit ein bevorzugtes Angriffsziel...

Lukas Hügle

Lukas Hügle

Co-Founder & CTO

10. Jan. 2026 5 Min.
OWASP API Security Top 10 2023

APIs sind das Rückgrat moderner Anwendungen. Sie verbinden Frontends mit Backends, ermöglichen Microservice-Architekturen und treiben mobile Apps an. Doch genau diese zentrale Rolle macht sie zu einem bevorzugten Angriffsziel. Die OWASP (Open Worldwide Application Security Project) hat 2023 eine aktualisierte Liste der zehn kritischsten API-Sicherheitsrisiken veröffentlicht.

Warum API-Sicherheit wichtig ist

Über 80% des Internet-Traffics läuft heute über APIs. Gleichzeitig steigen die Angriffe auf API-Endpunkte exponentiell. Traditionelle Sicherheitsmaßnahmen wie Web Application Firewalls (WAFs) erkennen viele API-spezifische Angriffe nicht, da diese oft logische Schwachstellen ausnutzen statt technische.

Die OWASP API Security Top 10 2023 im Überblick

Die folgende Liste beschreibt die zehn kritischsten Sicherheitsrisiken für APIs, geordnet nach Schwere und Häufigkeit.

API1:2023 - Broken Object Level Authorization (BOLA)

Beschreibung

BOLA tritt auf, wenn eine API nicht ausreichend prüft, ob ein Benutzer berechtigt ist, auf ein bestimmtes Objekt zuzugreifen. Angreifer können IDs in API-Anfragen manipulieren, um auf Daten anderer Benutzer zuzugreifen.

Beispiel

Ein Angreifer ändert /api/users/123/orders zu /api/users/456/orders und erhält Zugriff auf fremde Bestellungen, weil die API die Objektzugehörigkeit nicht prüft.

Gegenmaßnahmen

  • Implementierung von Autorisierungsprüfungen auf Objektebene bei jeder API-Anfrage
  • Verwendung unvorhersehbarer Objekt-IDs (z.B. UUIDs statt sequentieller IDs)
  • Automatisierte Tests mit verschiedenen Benutzerkontexten

API2:2023 - Broken Authentication

Beschreibung

Schwachstellen in der Authentifizierung ermöglichen es Angreifern, die Identität anderer Benutzer anzunehmen. Dazu gehören schwache Token-Generierung, fehlende Token-Validierung und unsichere Passwort-Recovery-Flows.

Beispiel

Eine API akzeptiert abgelaufene JWT-Tokens oder validiert die Signatur nicht korrekt, was Token-Fälschung ermöglicht.

Gegenmaßnahmen

  • Strikte Token-Validierung mit Ablaufzeiten und Signaturprüfung
  • Multi-Faktor-Authentifizierung für sensible Operationen
  • Rate Limiting für Authentifizierungs-Endpoints

API3:2023 - Broken Object Property Level Authorization

Beschreibung

Diese Schwachstelle entsteht, wenn eine API den Zugriff auf bestimmte Objekteigenschaften nicht ausreichend einschränkt. Angreifer können sensible Felder lesen oder schreiben, die ihnen nicht zugänglich sein sollten.

Beispiel

Ein Benutzer sendet ein Update mit {"role": "admin"} im Request-Body, und die API übernimmt die Rollenänderung, weil sie Eingabefelder nicht filtert.

Gegenmaßnahmen

  • Whitelisting erlaubter Felder für jede Operation
  • Trennung von Lese- und Schreibmodellen (DTOs)
  • Sensible Felder aus API-Responses entfernen

API4:2023 - Unrestricted Resource Consumption

Beschreibung

APIs, die keine Limits für Ressourcenverbrauch setzen, sind anfällig für Denial-of-Service-Angriffe. Dies umfasst fehlende Rate Limits, keine Begrenzung der Payload-Größe und unbeschränkte Abfragekomplexität.

Beispiel

Ein Angreifer sendet eine GraphQL-Query mit tief verschachtelten Beziehungen, die den Server überlastet und für andere Nutzer unerreichbar macht.

Gegenmaßnahmen

  • Implementierung von Rate Limiting und Throttling
  • Begrenzung der maximalen Payload-Größe
  • Abfragekomplexitäts-Limits für GraphQL-APIs

API5:2023 - Broken Function Level Authorization

Beschreibung

Wenn Administrative Endpunkte oder sensible Funktionen nicht ausreichend geschützt sind, können reguläre Benutzer privilegierte Aktionen ausführen.

Beispiel

Ein regulärer Benutzer ändert GET /api/users zu DELETE /api/users/123 und kann Benutzerkonten löschen, weil die Funktionsberechtigung nicht geprüft wird.

Gegenmaßnahmen

  • Rollenbasierte Zugriffskontrolle (RBAC) für alle Endpunkte
  • Administrative Funktionen in separate API-Segmente isolieren
  • Standardmäßig alle Zugriffe verweigern (Deny by Default)

API6:2023 - Unrestricted Access to Sensitive Business Flows

Beschreibung

APIs, die geschäftskritische Flows exponieren, ohne deren automatisierte Nutzung zu beschränken, sind anfällig für Missbrauch durch Bots und automatisierte Angriffe.

Beispiel

Ein Angreifer automatisiert den Kaufprozess eines limitierten Produkts und kauft den gesamten Bestand auf, bevor reguläre Kunden eine Chance haben.

Gegenmaßnahmen

  • Bot-Erkennung und CAPTCHA für kritische Business Flows
  • Gerätefingerprinting und Verhaltensanalyse
  • Geschäftslogik-basierte Rate Limits

API7:2023 - Server Side Request Forgery (SSRF)

Beschreibung

SSRF tritt auf, wenn eine API benutzerseitig bereitgestellte URLs abruft, ohne diese ausreichend zu validieren. Angreifer können die API nutzen, um interne Dienste zu erreichen.

Beispiel

Eine API nimmt eine URL als Parameter entgegen, um ein Bild herunterzuladen. Ein Angreifer übergibt http://169.254.169.254/latest/meta-data/ und erhält AWS-Metadaten inklusive Credentials.

Gegenmaßnahmen

  • Strikte URL-Validierung und Whitelisting erlaubter Domains
  • Blockierung von Anfragen an interne Netzwerke und Cloud-Metadaten-Endpoints
  • Verwendung eines Proxy-Servers für ausgehende Anfragen

API8:2023 - Security Misconfiguration

Beschreibung

Fehlkonfigurationen auf jeder Ebene des API-Stacks können Sicherheitslücken öffnen. Dazu gehören unnötig offene Ports, fehlende Security-Header, aktivierter Debug-Modus und Standard-Credentials.

Beispiel

Eine API lässt CORS-Anfragen von jeder Origin zu (Access-Control-Allow-Origin: *) und exponiert dadurch sensible Daten an beliebige Websites.

Gegenmaßnahmen

  • Automatisierte Konfigurationsaudits und Hardening
  • Restriktive CORS-Policies und Security-Header
  • Deaktivierung von Debug-Modi und unnötigen Features in Produktion

API9:2023 - Improper Inventory Management

Beschreibung

Organisationen verlieren den Überblick über ihre API-Landschaft. Veraltete API-Versionen, undokumentierte Endpunkte und vergessene Test-Umgebungen bieten Angreifern Einstiegspunkte.

Beispiel

Eine alte API-Version (/api/v1/) bleibt nach dem Upgrade auf v2 aktiv und enthält Schwachstellen, die in der neuen Version längst behoben wurden.

Gegenmaßnahmen

  • Vollständige API-Inventarisierung und Dokumentation
  • Automatische Erkennung von Shadow-APIs und undokumentierten Endpunkten
  • Lifecycle-Management mit klaren Deprecation-Policies

API10:2023 - Unsafe Consumption of APIs

Beschreibung

Entwickler vertrauen häufig Daten von Drittanbieter-APIs, ohne diese ausreichend zu validieren. Wenn ein Drittanbieter kompromittiert wird, können schädliche Daten in das eigene System gelangen.

Beispiel

Eine Anwendung integriert eine externe Wetter-API und rendert deren Response direkt im Frontend. Ein Angreifer kompromittiert die Wetter-API und injiziert bösartiges JavaScript.

Gegenmaßnahmen

  • Validierung und Sanitisierung aller Daten von Drittanbieter-APIs
  • Timeout- und Fehlerbehandlung für externe API-Aufrufe
  • Strikte Input-Validierung unabhängig von der Datenquelle

Fazit

Die OWASP API Security Top 10 2023 zeigt deutlich: API-Sicherheit erfordert einen ganzheitlichen Ansatz. Traditionelle Sicherheitstools reichen nicht aus, um die logischen und kontextbezogenen Schwachstellen zu erkennen, die moderne APIs bedrohen.

Automatisierte, agentenbasierte API-Security-Plattformen wie Venedy können diese Lücke schließen, indem sie APIs kontinuierlich und kontextbewusst auf alle OWASP-Top-10-Schwachstellen testen.

Quellen

  • OWASP API Security Project: API Security Top 10 2023
  • OWASP Foundation: API Security Risks Overview

Ihre APIs testen?

Erfahren Sie, wie Venedy kontextbezogene Schwachstellen automatisch aufdeckt.

Newsletter