API-Sicherheit: OWASP API Security Top 10 (2023) erklärt

APIs sind das Rückgrat moderner Software. Mobile Apps, Single-Page-Anwendungen, Microservices, Partner-Integrationen und inzwischen auch KI-Agenten kommunizieren fast ausschließlich über Schnittstellen (APIs). Genau deshalb sind APIs zum bevorzugten Angriffsziel geworden: Sie legen Geschäftslogik, Objekt-Referenzen und Datenstrukturen offen, oft in einer Direktheit, die klassische, serverseitig gerenderte Webanwendungen nie hatten.

Die OWASP API Security Top 10 sind die maßgebliche Referenzliste für diese spezifischen Risiken. Die aktuelle Fassung ist die Edition 2023, eine grundlegende Überarbeitung der ersten Liste von 2019. Dieser Artikel erklärt alle zehn Kategorien editionsscharf (also mit den exakten Original-IDs und -Namen von 2023), zeigt für jede Kategorie ein verwundbares und ein sicheres Code-Beispiel in einer durchgehenden Node.js/Express-API, ordnet die wichtigsten Änderungen von 2019 auf 2023 ein und verankert das Ganze in aktuellen Vorfällen von 2023 bis 2025.

Das Besondere an dieser Übersicht: Statt zehn abstrakter Definitionen bekommen Sie eine zusammenhängende Beispiel-API, die Sie Kategorie für Kategorie erst kaputt und dann repariert sehen. So wird aus der Liste ein praktischer Leitfaden, den Sie direkt gegen Ihren eigenen Code halten können.

Was sind die OWASP API Security Top 10?

Das OWASP API Security Project ist ein community-getragenes Projekt der Open Worldwide Application Security Foundation. Es entstand, weil die allgemeinen OWASP Top 10 (für klassische Webanwendungen) die typischen Schwachstellenmuster von APIs nur unzureichend abbilden. APIs exponieren direkte Objekt-Referenzen, feingranulare Business-Funktionen und maschinenlesbare Datenstrukturen anders, als es eine klassische Webseite mit serverseitigem Rendering tut.

Die zentrale Erkenntnis der 2023er-Überarbeitung: Viele der schwerwiegendsten API-Vorfälle sind technisch vollkommen valide Anfragen. Der Angreifer nutzt echte, gültige Zugangsdaten, ruft einen echten Endpunkt auf und bekommt echte Daten zurück. Es braucht kein Exploit-Kit, keine Memory-Corruption, keine klassische Injection. Genau deshalb ist Autorisierung (wer darf was mit welchem Objekt, welcher Eigenschaft, welcher Funktion) das dominierende Thema der Liste, nicht Verschlüsselung oder Authentifizierung allein.

Sechs von zehn Kategorien drehen sich im Kern um Autorisierungsfehler. Das deutsche Fachmedium Security-Insider bringt es auf den Punkt: Vier der Top-fünf-Risiken betreffen Authentifizierung und Autorisierung. Wer API-Sicherheit verstehen will, muss also zuallererst verstehen, warum gültige Anfragen falsche Antworten produzieren können. Die grundlegende Verwaltung von Identitäten und Berechtigungen, auf der all diese Prüfungen aufsetzen, behandeln wir im Beitrag zu Identity and Access Management (IAM).

Die zehn Kategorien der Edition 2023 im Überblick

Ein wichtiger Hinweis vorweg: Eine offizielle deutsche Übersetzung der 2023er-Liste durch OWASP gibt es nicht (nur eine 2019er-PDF-Fassung). Deutschsprachige Artikel zur 2023er-Liste, auch dieser, verwenden daher eigene Übersetzungen. Die englischen Original-IDs und -Namen sind maßgeblich, und wir nutzen sie durchgehend.

Unsere Beispiel-API

Alle Code-Beispiele in diesem Artikel gehören zu einer kleinen fiktiven REST-API in Node.js mit dem Framework Express. Sie verwaltet Nutzer, Bestellungen und Transaktionen. Eine authenticate-Middleware setzt bei gültigem Token das Objekt req.user (mit id und role), und ein Datenzugriffs-Layer db kapselt die Datenbank. So sehen Sie jedes Risiko im selben Kontext, erst verwundbar, dann abgesichert.

API1:2023 Broken Object Level Authorization (BOLA)

BOLA ist seit 2019 unangefochten Platz 1 und blieb es auch 2023. Der Fehler: Die API akzeptiert eine Objekt-ID als Eingabe, prüft aber nicht, ob der anfragende Nutzer dieses konkrete Objekt überhaupt sehen oder ändern darf. Ein authentifizierter Nutzer ändert einfach eine ID in der URL und erhält fremde Daten.

Begrifflich beschreibt BOLA dasselbe Schwachstellen-Cluster wie IDOR (Insecure Direct Object References). OWASP hat den Fokus nur vom Angriffsmechanismus (manipulierbare Referenz) auf die Ursache (fehlende Autorisierungsprüfung) verschoben. Wenn Sie die IDOR-Grundlagen vertiefen wollen, lesen Sie unseren Beitrag zu Broken Access Control und IDOR.

Der Anbieter Salt Security schätzt, dass BOLA in rund 40 Prozent aller API-Angriffe eine Rolle spielt (Vendor-Angabe ohne offengelegte Methodik, daher als Größenordnung zu verstehen). Was BOLA so gefährlich macht, beschreibt Snyk treffend: Es braucht keine Hacking-Tools, nur eine geänderte Ziffer, und weil Anfrage wie Antwort technisch legitim aussehen, laufen klassische Web Application Firewalls oft ins Leere.

Verwundbar: Der Endpunkt gibt jede Bestellung anhand ihrer ID zurück, ohne den Besitzer zu prüfen.

app.get("/api/orders/:orderId", authenticate, async (req, res) => {
  const order = await db.orders.findById(req.params.orderId);
  res.json(order);
});

Sicher: Vor der Ausgabe wird geprüft, ob das Objekt dem anfragenden Nutzer gehört.

app.get("/api/orders/:orderId", authenticate, async (req, res) => {
  const order = await db.orders.findById(req.params.orderId);
  if (!order) {
    return res.status(404).json({ error: "Not found" });
  }
  if (order.userId !== req.user.id) {
    return res.status(403).json({ error: "Access denied" });
  }
  res.json(order);
});

Realer Fall: Beim T-Mobile-Vorfall 2023 griffen Angreifer über eine einzige API auf Daten von rund 37 Millionen Kunden zu, ein klassisches BOLA-Muster. Dieser Vorfall trug mit dazu bei, dass T-Mobile 2024 ein Settlement mit der US-Aufsichtsbehörde FCC über 31,5 Millionen US-Dollar schloss. Die oft zitierte Vergleichszahlung von 350 Millionen US-Dollar gehört dagegen zum separaten, nicht API-spezifischen Breach vom August 2021 mit rund 76,6 Millionen Betroffenen. Auch der Peloton-Vorfall (2021) fällt in diese Kategorie: Über vertauschte Nutzer-IDs waren fremde Profil- und Trainingsdaten abrufbar.

API2:2023 Broken Authentication

Platz 2, ebenfalls seit 2019 unverändert. Hier geht es nicht darum, was jemand darf, sondern wer er ist: Schwächen bei der Verifikation der Identität. Typische Muster sind fehlendes Rate-Limiting auf Login- und Token-Endpunkten (ein offenes Tor für Brute-Force-Angriffe), JWTs, die mit {"alg":"none"} akzeptiert werden, nicht validierte Ablaufzeiten, Tokens in URLs (die dadurch in Logs landen) und fehlende Re-Authentifizierung bei sensiblen Aktionen. 2019 hieß die Kategorie noch "Broken User Authentication", 2023 wurde sie auf Maschine-zu-Maschine-Authentifizierung verallgemeinert.

Ein häufiger, schwerer Fehler: das Token dekodieren, ohne seine Signatur zu prüfen. Damit kann ein Angreifer den Payload beliebig fälschen.

Verwundbar: Das Token wird nur dekodiert, nicht verifiziert.

const jwt = require("jsonwebtoken");

function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  // Dekodiert den Payload, ohne die Signatur zu pruefen
  req.user = jwt.decode(token);
  next();
}

Sicher: Die Signatur wird verifiziert, der erlaubte Algorithmus fest verdrahtet, das Ablaufdatum geprüft.

const jwt = require("jsonwebtoken");

function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  if (!token) {
    return res.status(401).json({ error: "Missing token" });
  }
  try {
    // Prueft Signatur und Ablauf, erzwingt den erlaubten Algorithmus
    req.user = jwt.verify(token, process.env.JWT_SECRET, {
      algorithms: ["HS256"]
    });
    next();
  } catch (err) {
    return res.status(401).json({ error: "Invalid token" });
  }
}

Ergänzend gehören auf Login- und Token-Endpunkte harte Ratenbegrenzungen (siehe API4), damit Brute-Force-Versuche ins Leere laufen, sowie Multi-Faktor-Authentifizierung für sensible Konten.

Realer Fall: Beim USPS-Datenleck (2018) konnte laut Recherchen jeder authentifizierte Nutzer über die API Kontodetails abfragen, betroffen waren rund 60 Millionen Konten. Beim 3Commas-Vorfall (2022) führte der Missbrauch von API-Schlüsseln zu einem gemeldeten Verlust von rund 22 Millionen US-Dollar.

API3:2023 Broken Object Property Level Authorization (BOPLA)

BOPLA ist die wichtigste strukturelle Neuerung von 2023. Die Kategorie verschmilzt zwei frühere: API3:2019 Excessive Data Exposure und API6:2019 Mass Assignment. OWASP begründet das mit der gemeinsamen Ursache, der fehlenden oder fehlerhaften Autorisierungsprüfung auf Ebene einzelner Objekteigenschaften. Während BOLA fragt, ob Sie das Objekt sehen dürfen, fragt BOPLA, ob Sie diese einzelne Eigenschaft lesen oder schreiben dürfen.

Am besten versteht man BOPLA in zwei Unterformen.

Form 1: Excessive Data Exposure (zu viel herausgeben)

Die API gibt mehr Felder zurück, als der Nutzer sehen darf, etwa Passwort-Hash, interne Rolle oder eine Sozialversicherungsnummer. Dass das Frontend diese Felder ausblendet, hilft nicht: In der Netzwerkinspektion sind sie sichtbar.

Verwundbar: Das komplette Nutzerobjekt wandert in die Antwort.

app.get("/api/users/:id", authenticate, async (req, res) => {
  const user = await db.users.findById(req.params.id);
  // Gibt den kompletten Datensatz zurueck, inklusive passwordHash und internalRole
  res.json(user);
});

Sicher: Eine explizite Allow-List bestimmt, welche Felder ausgegeben werden.

app.get("/api/users/:id", authenticate, async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) {
    return res.status(404).json({ error: "Not found" });
  }
  res.json({
    id: user.id,
    name: user.name,
    email: user.email
  });
});

Form 2: Mass Assignment (zu viel hereinlassen)

Der umgekehrte Fehler: Die API übernimmt Felder aus dem Request-Body ungeprüft. Ein Nutzer will eigentlich nur seinen Namen ändern, schmuggelt aber "role": "admin" in den Payload und eskaliert damit seine Rechte.

Verwundbar: Der gesamte Request-Body wird blind in die Datenbank geschrieben.

app.patch("/api/users/:id", authenticate, async (req, res) => {
  // Kopiert jedes Feld aus dem Request-Body ungeprueft
  const updated = await db.users.update(req.params.id, req.body);
  res.json(updated);
});

Sicher: Nur ausdrücklich erlaubte Felder werden übernommen.

app.patch("/api/users/:id", authenticate, async (req, res) => {
  const allowed = ["name", "email"];
  const updates = {};
  for (const field of allowed) {
    if (field in req.body) {
      updates[field] = req.body[field];
    }
  }
  const updated = await db.users.update(req.params.id, updates);
  res.json(updated);
});

Die Grundregel für beide Formen: Definieren Sie explizite Allow-Lists für Ein- und Ausgabe, arbeiten Sie mit festen Response-Schemas und übergeben Sie niemals ein rohes Request-Objekt direkt an ein ORM.

API4:2023 Unrestricted Resource Consumption

2019 hieß die Kategorie "Lack of Resources & Rate Limiting", 2023 wurde sie verallgemeinert: Es geht nicht nur um klassisches Request-Rate-Limiting, sondern um jede Form unbeschränkten Verbrauchs, CPU, Arbeitsspeicher, Speicherplatz, Bandbreite und teure Drittanbieter-Aufrufe. Fehlen Limits, kann ein Angreifer den Dienst überlasten oder die Betriebskosten in die Höhe treiben.

Typische Auslöser: kein Limit bei rechenintensiven Operationen (Bildverarbeitung, ML-Inferenz), keine maximalen Payload-Größen, unbegrenzte Listen-Rückgaben und fehlende Tiefen- oder Komplexitätslimits bei GraphQL. Ein dokumentiertes Beispiel: Eine Finanz-API ohne Pagination-Limit erzeugte für ein besonders aktives Konto eine 90-sekündige Datenbankabfrage, die den Dienst für alle Nutzer ausbremste.

Verwundbar: Der Endpunkt gibt sämtliche Transaktionen ohne Begrenzung zurück.

app.get("/api/transactions", authenticate, async (req, res) => {
  // Gibt saemtliche Transaktionen ohne Limit zurueck
  const transactions = await db.transactions.findAll({ userId: req.user.id });
  res.json(transactions);
});

Sicher: Eine globale Ratenbegrenzung plus eine erzwungene Pagination-Obergrenze.

const rateLimit = require("express-rate-limit");

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 Minuten
  limit: 100 // maximal 100 Anfragen pro IP und Fenster (bis v6: Option "max")
});
app.use("/api/", apiLimiter);

app.get("/api/transactions", authenticate, async (req, res) => {
  const limit = Math.min(parseInt(req.query.limit, 10) || 50, 100);
  const offset = parseInt(req.query.offset, 10) || 0;
  const transactions = await db.transactions.findAll({
    userId: req.user.id,
    limit,
    offset
  });
  res.json(transactions);
});

API5:2023 Broken Function Level Authorization (BFLA)

BFLA sitzt seit 2019 unverändert auf Platz 5. Der Unterschied zu BOLA ist zentral: BOLA betrifft fremde Daten (ein fremdes Objekt), BFLA betrifft eine fremde Funktion oder Aktion (etwa eine Admin-Löschfunktion, aufgerufen von einem normalen Nutzer). Häufig prüfen APIs die Authentifizierung (ist das Token gültig?), aber nicht die Autorisierung (hat dieser Nutzer die passende Rolle?).

Ein typischer Angriff sieht so aus:

DELETE /api/admin/users/8827
Authorization: Bearer <token_eines_normalen_nutzers>

Wenn serverseitig keine Rollenprüfung existiert, gelingt das Löschen trotz eines nur gültigen, aber nicht privilegierten Tokens.

Verwundbar: Der Admin-Endpunkt prüft nur, dass jemand eingeloggt ist.

app.delete("/api/admin/users/:id", authenticate, async (req, res) => {
  await db.users.delete(req.params.id);
  res.json({ deleted: true });
});

Sicher: Eine wiederverwendbare Rollen-Middleware erzwingt die passende Berechtigung.

function requireRole(role) {
  return (req, res, next) => {
    if (req.user.role !== role) {
      return res.status(403).json({ error: "Forbidden" });
    }
    next();
  };
}

app.delete(
  "/api/admin/users/:id",
  authenticate,
  requireRole("admin"),
  async (req, res) => {
    await db.users.delete(req.params.id);
    res.json({ deleted: true });
  }
);

Administrative Funktionen sollten grundsätzlich von regulären Nutzeraktionen getrennt und rollenbasiert geschützt werden (RBAC), am besten nach dem Least-Privilege-Prinzip.

API6:2023 Unrestricted Access to Sensitive Business Flows

Eine der neuen Kategorien von 2023 und konzeptionell die anspruchsvollste. Hier gibt es keinen technischen Bug im klassischen Sinn: Die API funktioniert genau wie designt. Das Problem ist, dass ein sensibler Geschäftsablauf ohne Schutz gegen automatisierten Missbrauch in großem Maßstab exponiert wird. ApyGuard formuliert es zugespitzt: Angreifer nutzen die API schneller und in größerem Umfang, als es ein legitimer Nutzer je täte.

Typische Missbrauchsmuster:

• Inventory Hoarding: Bots rufen bei einem Produkt-Drop wiederholt den Kauf-Endpunkt auf und räumen den gesamten Bestand ab.
• Referral-Betrug: Automatisierte Kontoerstellung greift tausendfach Willkommensboni ab.
• Ticket- und Terminmissbrauch: Skripte blockieren alle Slots schneller als Menschen. Security-Insider nennt die Flugticket-Manipulation als anschauliches Beispiel, Zerberos die bot-gesteuerte Ticketblockade.

Der Schutz ist kein einzelner Fix, sondern eine Kombination aus Geschwindigkeitslimits pro Nutzer, Bot-Erkennung, Device Fingerprinting, Verhaltensanalyse und, bei Bedarf, CAPTCHA oder Proof-of-Work-Challenges.

Verwundbar: Der Checkout-Endpunkt kennt keinerlei Missbrauchsschutz.

// createOrder steht fuer die Bestell-Logik unserer Beispiel-API
app.post("/api/checkout", authenticate, async (req, res) => {
  const order = await createOrder(req.user.id, req.body.items);
  res.json(order);
});

Sicher: Ein nutzerbezogenes Geschwindigkeitslimit und eine Anti-Bot-Prüfung schalten sich davor.

const rateLimit = require("express-rate-limit");

// Begrenzt Checkouts pro authentifiziertem Nutzer, nicht nur pro IP
const purchaseVelocityLimit = rateLimit({
  windowMs: 60 * 1000,
  limit: 5,
  keyGenerator: (req) => req.user.id
});

// verifyHumanChallenge steht hier fuer eine Anti-Bot-Middleware
// (CAPTCHA oder Proof-of-Work), typischerweise von einem Dienst bereitgestellt
app.post(
  "/api/checkout",
  authenticate,
  purchaseVelocityLimit,
  verifyHumanChallenge,
  async (req, res) => {
    const order = await createOrder(req.user.id, req.body.items);
    res.json(order);
  }
);

API7:2023 Server Side Request Forgery (SSRF)

Ebenfalls neu 2023 als eigene Top-10-Kategorie. SSRF entsteht, wenn eine API eine URL als Eingabe entgegennimmt und diese serverseitig abruft, ohne das Ziel zu validieren. Angreifer zielen damit auf interne Dienste oder, besonders gefährlich, auf Cloud-Metadaten-Endpunkte wie 169.254.169.254, über die sich in vielen Umgebungen IAM-Zugangsdaten abgreifen lassen. Veracode nennt die Verbreitung von Microservices und Cloud-Architekturen als Grund, warum SSRF an Bedeutung gewann.

Ein typischer Angriffsversuch:

POST /api/import
{"source_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Verwundbar: Die API ruft jede vom Client gelieferte URL ab.

const axios = require("axios");

app.post("/api/import", authenticate, async (req, res) => {
  // Ruft jede beliebige vom Client gelieferte URL ab
  const response = await axios.get(req.body.sourceUrl);
  res.json(response.data);
});

Sicher: Schema und Host werden gegen eine Allow-List geprüft, private, Loopback- und Link-Local-IPv4-Bereiche werden zusätzlich blockiert.

const axios = require("axios");
const dns = require("dns").promises;

const ALLOWED_HOSTS = ["files.example.com", "cdn.example.com"];

function isPrivateIp(ip) {
  return (
    ip.startsWith("10.") ||
    ip.startsWith("127.") ||
    ip.startsWith("192.168.") ||
    ip.startsWith("169.254.") ||
    /^172\.(1[6-9]|2\d|3[01])\./.test(ip)
  );
}

app.post("/api/import", authenticate, async (req, res) => {
  let target;
  try {
    target = new URL(req.body.sourceUrl);
  } catch (err) {
    return res.status(400).json({ error: "Invalid URL" });
  }
  if (target.protocol !== "https:" || !ALLOWED_HOSTS.includes(target.hostname)) {
    return res.status(400).json({ error: "URL not allowed" });
  }
  const { address } = await dns.lookup(target.hostname);
  if (isPrivateIp(address)) {
    return res.status(400).json({ error: "Blocked target" });
  }
  // maxRedirects: 0 verhindert, dass ein erlaubter Host auf interne Ziele umleitet
  const response = await axios.get(target.toString(), { maxRedirects: 0 });
  res.json(response.data);
});

Ein wichtiger Hinweis zur Einordnung: Die IP-Prüfung in diesem Beispiel ist nur Defense-in-Depth zusätzlich zur Host-Allow-List, nicht die eigentliche Schutzschicht. Eine produktionsreife SSRF-Abwehr muss darüber hinaus IPv6-Adressbereiche (etwa ::1 und fc00::/7) und DNS-Rebinding berücksichtigen (der Host kann zwischen Prüfung und Abruf auf eine andere IP aufgelöst werden). Dafür bieten sich geprüfte Bibliotheken wie ssrf-req-filter an.

Realer Fall: Der Capital-One-Breach 2019 gilt als Lehrbuchbeispiel: Eine SSRF-Schwachstelle erlaubte es, AWS-Metadaten abzufragen, IAM-Zugangsdaten zu extrahieren und auf S3-Buckets mit rund 100 Millionen Kundendatensätzen zuzugreifen. Auch der Shopify-Vorfall 2020 (SSRF über eine Screenshot-Funktion) fällt in diese Kategorie.

API8:2023 Security Misconfiguration

Der Name ist seit 2019 unverändert, die Kategorie rückte aber um einen Platz nach oben (von API7:2019 auf API8:2023), als Injection wegfiel. Sie ist der große Sammelbegriff für falsch gesetzte Sicherheitsparameter: zu permissive CORS-Header, offene Debug-Endpunkte, Standard-Zugangsdaten, fehlende Transportverschlüsselung, ausführliche Fehlermeldungen mit Stack-Traces und unnötig aktivierte HTTP-Methoden. Besonders tückisch ist bei CORS die Origin-Reflexion mit Credentials: Der Server spiegelt den Origin-Header jeder Anfrage ungeprüft in Access-Control-Allow-Origin zurück und setzt zugleich Access-Control-Allow-Credentials: true. Damit kann jede beliebige Angreifer-Website authentifizierte Anfragen im Namen des Opfers stellen und die Antworten lesen. Die naive Kombination aus Wildcard (Access-Control-Allow-Origin: *) und Credentials wird von Browsern gemäß Fetch-Spezifikation verworfen, genau deshalb weichen Entwickler oft auf die Reflexion aus, die wirklich gefährlich ist.

Verwundbar: Origin-Reflexion mit Credentials und ein offener Debug-Endpunkt, der die Umgebungsvariablen preisgibt.

const cors = require("cors");

app.use(cors({
  origin: true, // spiegelt jeden Request-Origin zurueck
  credentials: true // und erlaubt zugleich Credentials: ausnutzbar von jeder Website
}));

app.get("/debug", (req, res) => {
  res.json({ env: process.env });
});

Sicher: Restriktive CORS-Konfiguration, Sicherheits-Header über Helmet, kein Debug-Endpunkt und ein Error-Handler, der keine Stack-Traces preisgibt.

const cors = require("cors");
const helmet = require("helmet");

app.use(helmet());
app.use(cors({
  origin: ["https://app.example.com"],
  credentials: true
}));

// Keine Debug-Endpunkte in Produktion, den x-powered-by-Header entfernen
app.disable("x-powered-by");

app.use((err, req, res, next) => {
  // Keine Stack-Traces an den Client geben
  console.error(err);
  res.status(500).json({ error: "Internal server error" });
});

Realer Fall: Beim SVR-Tracking-Vorfall 2017 exponierte ein falsch konfigurierter, öffentlich zugänglicher AWS-S3-Bucket rund 540.000 Accounts des Fahrzeug-Tracking-Dienstes, inklusive Kunden-Logins und Fahrzeugdaten. Streng genommen lag der Fehler in der Storage-Schicht und nicht in der API selbst, die Grundursache ist aber genau die, auf die diese Kategorie zielt: eine sicherheitsrelevante Konfiguration, die offen stehen blieb.

API9:2023 Improper Inventory Management

2019 noch "Improper Assets Management", 2023 umbenannt mit Fokus auf ein vollständiges, aktuelles Inventar aller API-Elemente: Hosts, Umgebungen, Versionen, Dokumentation. Der Kernbegriff ist die Shadow API: ein undokumentierter, vergessener oder außerhalb der offiziellen Inventarisierung laufender Endpunkt. Quellen solcher Schatten-APIs sind veraltete Versionen, die neben aktuellen mit weniger Kontrollen weiterlaufen, undokumentierte Entwickler-Routen und ins Internet erreichbare Staging-Umgebungen mit produktionsnahen Daten.

Verwundbar: Eine alte v1-Route bleibt nach dem v2-Start online, ohne Authentifizierung und undokumentiert.

// Legacy-Endpunkt, nach dem v2-Start online geblieben, ohne Auth und undokumentiert
app.get("/api/v1/users/:id/export", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user);
});

Sicher: Die veraltete Version wird formal stillgelegt, mit Sunset-Header und klarer Statusmeldung.

// v1 ist offiziell abgekuendigt: authentifiziert und mit Sunset-Termin
app.get("/api/v1/users/:id/export", authenticate, (req, res) => {
  res.set("Sunset", "Sat, 31 Jan 2026 23:59:59 GMT");
  res.status(410).json({ error: "This API version has been retired" });
});

Praktisch gehören dazu ein kontinuierliches API-Discovery, eine gepflegte OpenAPI-Dokumentation, klare Versionierungs- und Deprecation-Strategien und Monitoring auf neu auftauchende, nicht erfasste Endpunkte.

API10:2023 Unsafe Consumption of APIs

Die zweite komplett neue Kategorie von 2023. Sie ersetzt das frühere "Insufficient Logging & Monitoring" und dreht die Perspektive um: Nicht Ihre API wird angegriffen, sondern Ihre Anwendung vertraut den Antworten einer Drittanbieter-API blind. Entwickler behandeln externe API-Daten oft als vertrauenswürdiger als direkte Nutzereingaben, genau das ist der Fehler. Wird der Partner kompromittiert oder liefert er manipulierte Daten, verarbeitet Ihre Infrastruktur die Payload ohne Prüfung.

Ein anschauliches Szenario (nach ApyGuard): Die Datenbank eines Geolocation-Anbieters wird mit SQL-Injection-Strings in Städtenamen vergiftet. Ihre Anwendung fügt den gelieferten Städtenamen direkt in eine Query ein und führt so fremden Code aus.

Verwundbar: Die Antwort des Drittanbieters wandert ungeprüft in eine SQL-Query.

const axios = require("axios");

app.get("/api/city-info", authenticate, async (req, res) => {
  const geo = await axios.get(`https://geoprovider.example.com/lookup?ip=${req.ip}`);
  // Vertraut dem Drittanbieter-Feld und interpoliert es direkt in SQL
  const rows = await db.raw(
    `SELECT * FROM cities WHERE name = '${geo.data.city}'`
  );
  res.json(rows);
});

Sicher: Die externe Antwort wird validiert und ausschließlich parametrisiert verwendet.

const axios = require("axios");

app.get("/api/city-info", authenticate, async (req, res) => {
  const geo = await axios.get(`https://geoprovider.example.com/lookup?ip=${req.ip}`);
  const city = String(geo.data.city || "").slice(0, 100);
  if (!/^[\p{L}\s.'-]+$/u.test(city)) {
    return res.status(422).json({ error: "Unexpected provider response" });
  }
  // Parametrisierte Query, der Drittanbieter-Wert gilt als nicht vertrauenswuerdig
  const rows = await db.raw("SELECT * FROM cities WHERE name = ?", [city]);
  res.json(rows);
});

Behandeln Sie jede Antwort einer externen API als nicht vertrauenswürdigen Input: validieren, sanitisieren, parametrisieren. Wie gefährlich ungefilterte Werte in Datenbankabfragen sind, zeigt unser Beitrag zu den Grundlagen von SQL-Injection.

Was sich von 2019 auf 2023 geändert hat

Die Edition 2023 ist keine bloße Neuauflage, sondern eine strukturelle Überarbeitung auf Basis von vier zusätzlichen Jahren an Breach- und Bug-Bounty-Daten. Die wichtigsten Änderungen:

• Verschmelzung zu BOPLA (API3:2023): Aus API3:2019 "Excessive Data Exposure" und API6:2019 "Mass Assignment" wurde eine gemeinsame Kategorie mit Fokus auf die gemeinsame Ursache (Autorisierung auf Eigenschaftsebene).
• Drei neue Kategorien: API6:2023 "Unrestricted Access to Sensitive Business Flows", API7:2023 "Server Side Request Forgery" und API10:2023 "Unsafe Consumption of APIs".
• Umbenennungen mit erhaltenem Kern: API2:2019 "Broken User Authentication" wurde zu "Broken Authentication", API4:2019 "Lack of Resources & Rate Limiting" zu "Unrestricted Resource Consumption", API9:2019 "Improper Assets Management" zu "Improper Inventory Management".
• Weggefallen als eigenständige Kategorie: API8:2019 "Injection" ist 2023 keine eigene Top-10-Kategorie mehr (das Risiko besteht fort, wird aber nicht mehr separat gelistet). API10:2019 "Insufficient Logging & Monitoring" wurde durch "Unsafe Consumption of APIs" ersetzt.
• Unverändert in ID und Name: API1 (BOLA) und API5 (BFLA). Security Misconfiguration behielt den Namen, rückte aber von API7:2019 auf API8:2023 vor, als Injection wegfiel. API2 behielt Position 2, wurde aber (siehe oben) leicht umbenannt.

Dass Injection als eigene Kategorie fehlt, wird durchaus kritisch gesehen. Security-Insider merkt an, dass Injection-Risiken weiterhin kritisch sind, obwohl sie nicht mehr separat gelistet werden. Veracode vermutet als Grund (ausdrücklich als Einschätzung, nicht als offizielle OWASP-Begründung), dass neuere Frameworks eingebauten Schutz mitbringen. In der Praxis bleiben Injection-Schwachstellen relevant, sie tauchen 2023 nur an anderer Stelle auf, etwa als Folge von Unsafe Consumption (API10).

Aktuelle Bedrohungslage 2023 bis 2025

Ein Grund, warum viele Übersichten zu diesem Thema veraltet wirken: Sie zitieren fast ausschließlich Fälle von 2017 bis 2021. Die Bedrohungslage hat sich seither verschärft. Der jährliche API-ThreatStats-Report des Anbieters Wallarm liefert dazu aktuelle Zahlen (Vendor-Auswertung, daher mit entsprechendem Vorbehalt zu lesen):

• Über 50 Prozent der Schwachstellen im CISA-KEV-Katalog (der von der US-Behörde CISA geführten Liste tatsächlich ausgenutzter Schwachstellen) waren 2024 API-bezogen, gegenüber rund 20 Prozent im Jahr 2023. Grundgesamtheit ist der öffentliche KEV-Katalog, die Auswertung stammt von Wallarm.
• Fünf große Breaches aus 2024, alle als Zugriffskontroll- oder Authentifizierungsfehler eingeordnet: Dell (rund 49 Millionen Nutzer), Twilio (rund 33,4 Millionen verknüpfte Telefonnummern), Internet Archive (rund 31 Millionen Nutzer), Trello (rund 15 Millionen Nutzer) und ein Optus-Eintrag.

Zum Optus-Vorfall ist eine Einordnung nötig: Es handelt sich um einen einzigen Vorfall vom September 2022, bei dem eine ungeschützt exponierte API der Zugriffsweg war. Die Erstmeldungen sprachen von rund 9,8 Millionen Betroffenen, die australische Datenschutzbehörde OAIC legt ihrer Civil-Penalty-Klage (2025) rund 9,5 Millionen zugrunde. Die Datierung "2024" bei Wallarm bezeichnet die Aufnahme in den Report, nicht das Vorfallsjahr, und die 11,2 Millionen von Impart.ai weichen von allen Primärangaben ab. Belastbar ist also die Spanne von 9,5 Millionen (OAIC) bis 9,8 Millionen (Erstmeldung), das Vorfallsjahr ist eindeutig 2022.

Wallarm ordnet in seinem Report die Breaches einer eigenen, an OWASP angelehnten, aber nicht identischen Nomenklatur zu (etwa "Broken Access Control"), nicht der offiziellen OWASP-2023-Nummerierung. Wir mappen die Fälle daher auf die zugehörigen OWASP-Kategorien zurück, statt die Vendor-Bezeichnungen mit den offiziellen zu vermischen.

API-Sicherheit ist heute auch KI-Sicherheit

Ein Punkt, den die meisten Übersichten übersehen: Moderne KI-Integrationen sind im Kern API-Anwendungen. Chatbots, Agenten und Werkzeuge, die über das Model Context Protocol (MCP) angebunden werden, kommunizieren über HTTP-basierte API-Schnittstellen; MCP selbst spricht dabei JSON-RPC 2.0, nicht REST. Die Zertifizierungsorganisation GUTcert betont denselben Kernpunkt: MCP-Integrationen sind API-Endpunkte, API-Sicherheit wird damit zur Voraussetzung für sichere KI-Implementierungen. Das Protokoll und seine Angriffsfläche beleuchten wir ausführlich in unserem Beitrag zur MCP-Sicherheit.

Wallarm untermauert das mit Zahlen: Von 439 verfolgten KI-bezogenen Schwachstellen (CVEs) im Jahr 2024, ein Anstieg um 1.025 Prozent gegenüber 2023, seien 98,9 Prozent API-bezogen (auch dies eine Vendor-eigene Erhebung). Wer eine KI-Anwendung absichert, kommt an den OWASP API Security Top 10 also nicht vorbei. Wie sich die spezifischen KI-Angriffe daneben ausnehmen, behandeln wir in unserem Beitrag zu den Grundlagen der Prompt Injection.

Regulatorischer Kontext im DACH-Raum

Für Organisationen im deutschsprachigen Raum lohnt der Blick auf zwei Anker. Erstens die CWE-Abdeckung: Laut GUTcert referenzieren die OWASP API Security Top 10 rund 24 CWEs direkt und insgesamt 128 CWEs indirekt, was mehr als 10 Prozent des gesamten CWE-Katalogs entspricht (Zahl der Quelle GUTcert, gegen den offiziellen CWE-Katalog verifizierbar). Das macht die Liste zu einem strukturierten Prüfraster, nicht nur zu einer losen Themensammlung.

Zweitens die BSI-Technische-Richtlinie TR-03161: Sie fordert laut GUTcert bei Sicherheitsuntersuchungen die getrennte Prüfung von Client- und Server-Seite. Für regulierte Branchen (Gesundheitswesen, kritische Infrastruktur) ist das ein konkreter methodischer Anhaltspunkt, den die internationalen Quellen nicht abdecken. In den Kontext übergreifender Pflichten ordnet sich das über Rahmenwerke wie die NIS2-Richtlinie ein.

Häufige Fragen

Was ist die OWASP API Security Top 10?

Die OWASP API Security Top 10 sind die maßgebliche Referenzliste für die kritischsten Sicherheitsrisiken von APIs, gepflegt vom community-getragenen OWASP API Security Project. Die aktuelle Fassung ist die Edition 2023, eine grundlegende Überarbeitung der ersten Liste von 2019. Sie entstand, weil die allgemeinen OWASP Top 10 für Webanwendungen die typischen Schwachstellenmuster von APIs nur unzureichend abbilden. Sechs der zehn Kategorien drehen sich im Kern um Autorisierungsfehler.

Was ist der Unterschied zwischen BOLA und BFLA?

BOLA (API1:2023, Broken Object Level Authorization) betrifft fremde Daten: Die API prüft nicht, ob der anfragende Nutzer das konkrete Objekt (etwa eine Bestellung mit einer bestimmten ID) sehen oder ändern darf. BFLA (API5:2023, Broken Function Level Authorization) betrifft fremde Funktionen: Ein normaler Nutzer ruft eine Aktion auf, die einer anderen Rolle vorbehalten ist, etwa eine Admin-Löschfunktion. Kurz gesagt: BOLA ist das falsche Objekt, BFLA die falsche Funktion.

Was hat sich zwischen der OWASP API Top 10 2019 und 2023 geändert?

Drei Kategorien kamen 2023 neu hinzu: Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery und Unsafe Consumption of APIs. Excessive Data Exposure und Mass Assignment verschmolzen zu BOPLA (API3:2023). Injection (API8:2019) ist keine eigenständige Kategorie mehr, wodurch Security Misconfiguration von API7:2019 auf API8:2023 vorrückte. Insufficient Logging & Monitoring (API10:2019) wurde durch Unsafe Consumption of APIs ersetzt. BOLA (API1) und BFLA (API5) blieben in ID und Name unverändert.

Was ist die häufigste API-Schwachstelle?

BOLA (Broken Object Level Authorization) steht seit 2019 unangefochten auf Platz 1 der Liste. Der Anbieter Salt Security schätzt, dass BOLA in rund 40 Prozent aller API-Angriffe eine Rolle spielt (Vendor-Angabe ohne offengelegte Methodik). Gefährlich macht BOLA, dass es keine Hacking-Tools braucht: Eine geänderte ID in der URL genügt, und weil Anfrage wie Antwort technisch legitim aussehen, laufen klassische Web Application Firewalls oft ins Leere.

Wie sichere ich eine REST-API ab?

Prüfen Sie jeden Endpunkt entlang der Autorisierungsfragen der Top 10: Darf dieser Nutzer dieses Objekt sehen (BOLA), diese Eigenschaft lesen oder schreiben (BOPLA), diese Funktion ausführen (BFLA)? Dazu kommen verifizierte Token-Signaturen mit festem Algorithmus, harte Ratenbegrenzungen und Pagination-Obergrenzen, restriktive CORS-Konfiguration mit Sicherheits-Headern, ein gepflegtes API-Inventar ohne vergessene Alt-Versionen und die Grundregel, jede Antwort externer APIs als nicht vertrauenswürdigen Input zu behandeln.

Fazit

Die OWASP API Security Top 10 (2023) verschieben den Blick weg von klassischen technischen Exploits hin zur Autorisierung: Die gefährlichsten API-Angriffe bestehen aus vollkommen validen Anfragen, die nur die falsche Antwort bekommen. Sechs der zehn Kategorien und vier der Top fünf drehen sich um Autorisierungs- und Authentifizierungsfehler.

Wer die Liste ernst nimmt, prüft jeden Endpunkt entlang von vier Fragen: Darf dieser Nutzer dieses Objekt sehen (BOLA)? Darf er diese Eigenschaft lesen oder schreiben (BOPLA)? Darf er diese Funktion ausführen (BFLA)? Und ist der Ressourcenverbrauch, der Geschäftsablauf und jede externe Datenquelle angemessen begrenzt und validiert? Die durchgehende Beispiel-API in diesem Artikel zeigt für jede dieser Fragen den Unterschied zwischen verwundbarem und sicherem Code. Genau dieser Perspektivwechsel, von "läuft die Anfrage?" zu "darf sie das?", ist der Kern moderner API-Sicherheit.