Bob meldet sich mit seinem eigenen, gültigen Konto bei der Labor-API an, fordert GET /invoices/inv_100 an und erhält die Rechnung von Alice. Der Angreifer hat weder ein Token gestohlen noch die Anmeldung umgangen oder ein Passwort erraten. Bob hat einen Objektbezeichner in einer Route geändert; der Server akzeptierte dies, ohne zu prüfen, ob inv_100 tatsächlich Bob gehört. Die für die Verteidigung relevante Frage ist daher spezifischer und aussagekräftiger als die Frage, ob die Anmeldung funktioniert: Stellt die API bei jeder Anfrage sicher, dass die authentifizierte Identität (Principal) die betreffende Operation an diesem Objekt ausführen darf?
Bei dem hier verwendeten Beispiel handelt es sich um eine kleine REST-API mit den Endpunkten POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} und GET /admin/audit. Alice ist Eigentümerin von inv_100, Bob ist Eigentümer von inv_200, und ein Administrator darf Audit-Protokolle lesen. Ein Bedrohungsmodell (Threat Model) identifiziert, worüber der Angreifer bereits Kontrolle hat, welche Sicherheitsgrenze die Anfrage überschreitet, welches Ziel der Angreifer verfolgt und welche Entscheidung des Servers die Anfrage stoppen muss. In diesem Szenario kontrolliert Bob seine authentifizierte Anfrage sowie die invoiceId; er möchte auf Alices Rechnung zugreifen, weshalb die Autorisierung den Zugriff verweigern muss, bevor die Daten den Datenspeicher verlassen.
Die Authentifizierung stellt sicher, dass die Anfrage von Bob stammt. Die Autorisierung muss jedoch zusätzlich entscheiden, ob Bob inv_100 lesen darf. Werden diese Entscheidungen als eine einzige Prüfung zusammengefasst, entsteht eine Sicherheitslücke, da eine gültige Identität keine Aussage über Eigentumsverhältnisse oder administrative Berechtigungen trifft. Unser Ziel im Verlauf dieses Kurses ist es, genau diese API abzusichern und nachzuweisen, dass die jeweiligen Sicherheitsgrenzen auch unter Testbedingungen standhalten. Die folgende Übersicht veranschaulicht die Grenzen, die Bob überschreitet.
Dieses Diagramm veranschaulicht, warum eine Anfrage zwar die Authentifizierung bestehen, aber bei der Autorisierung oder dem Datenzugriff scheitern kann. Der Objektbezeichner (Object Identifier) wird erst dann zum Sicherheitsrisiko, wenn die API ihn zum Abrufen eines Datensatzes verwendet, ohne diesen Datensatz an den authentifizierten Akteur (Principal) zu binden.
Die fehlende Überprüfung der Eigentumsrechte entspricht dem Punkt API1:2023 Broken Object Level Authorization (BOLA) in den OWASP API Security Top 10 für 2023. Jeder Endpunkt, der eine vom Client gesteuerte Objekt-ID entgegennimmt, erfordert eine Autorisierungsentscheidung für dieses Objekt. GET /invoices/inv_100 und PUT /invoices/inv_100 sind eigenständige Vorgänge; daher ist für jeden eine separate Entscheidung erforderlich, selbst wenn sich beide auf dieselbe Rechnung beziehen.
Auch die weiteren Risiken im Anfangsbereich der Liste beziehen sich auf denselben Anfragepfad. API2:2023 Broken Authentication betrifft die Frage, ob die API Bob korrekt identifiziert. API3:2023 Broken Object Property Level Authorization befasst sich damit, ob eine an sich zulässige Antwort zu einer Rechnung Felder preisgibt oder akzeptiert, auf die Bob keinen Zugriff haben darf – etwa ein internes approvalLimit (Genehmigungslimit). API4:2023 Unrestricted Resource Consumption behandelt den Fall, dass Bob so häufig rechenintensive Anfragen sendet, dass die Kapazitätsgrenzen erreicht werden oder kostenpflichtige nachgelagerte Prozesse ausgelöst werden. API5:2023 Broken Function Level Authorization betrifft den Zugriff von Bob auf GET /admin/audit, obwohl ihm die entsprechenden Administratorrechte fehlen.
Jede Kategorie betrifft einen anderen Teil der Anfrage, doch allen gemeinsam ist die Überprüfung, ob der Server eine Sicherheitsgrenze durchsetzt, anstatt blind auf Client-Eingaben, ein bloßes Token oder den Namen eines Endpunkts zu vertrauen. Die Tabelle stellt die vom Angreifer vorgenommene Änderung, das zu schützende Ergebnis und die für Verteidiger erforderlichen Nachweise gegenüber.