IDOR / BOLA

Was ist IDOR / BOLA?

IDOR und BOLA benennen einen Fehler: Die Anwendung lässt einen Nutzer ein Objekt direkt referenzieren, über eine ID in der URL, im Request-Body oder in einem Token, und prüft nicht, ob dieser Nutzer auf dieses Objekt zugreifen darf. Ändere GET /api/orders/1042 zu /api/orders/1043, und du liest die Bestellung von jemand anderem. Ändere die userId im PUT-Body, und du bearbeitest ein fremdes Profil. Insecure Direct Object Reference ist der Begriff aus den OWASP Top 10 von 2007 und 2013; Broken Object Level Authorization ist der Name, den die OWASP API Security Top 10 ihm 2019 gab und als API1:2023 beibehielt, das API-Risiko Nummer eins.

Die zugrunde liegende Schwäche ist CWE-639, Authorization Bypass Through User-Controlled Key. Der Bug ist nicht, dass die ID sichtbar oder vorhersagbar ist; der Bug ist, dass der Server der ID vertraut, statt den Besitz zu prüfen.

Wo ist es definiert?

Die OWASP API Security Top 10, API1:2023 Broken Object Level Authorization, liefert Definition, Beispiele und Gegenmaßnahmen. Die OWASP Top 10 von 2021 ordnet den Fehler A01 Broken Access Control zu. Der OWASP Web Security Testing Guide beschreibt das Testverfahren unter WSTG-ATHZ-04, Testing for Insecure Direct Object References. CWE-639 von MITRE und die breitere CWE-284 (Improper Access Control) sind das, worauf SAST-Tools und Scanner verweisen. Ein naher Verwandter, API3:2023 Broken Object Property Level Authorization, deckt den Fall ab, dass das Objekt dir gehört, der Server dich aber Felder lesen oder schreiben lässt, die er nicht freigeben dürfte (Mass Assignment, Excessive Data Exposure).

Was es in der Praxis bedeutet

BOLA ist das Finding, das wir in Web-, API- und Mobile-Backend-Tests am häufigsten berichten, und es ist fast immer High oder Critical. Muster aus Projekten:

• Fortlaufende IDs machen es schlimmer, nicht erst möglich. Der Wechsel auf UUIDs begrenzt das Durchzählen, repariert aber die Autorisierungsprüfung nicht. Ein Angreifer, der eine UUID bekommt (aus einem geteilten Link, einem Log, einem zweiten Konto), kommt weiterhin hinein.
• Mobile- und IoT-Backends sind am stärksten betroffen. Die App zeigt nur deine Geräte, also nehmen Entwickler an, die API tue das auch. In Tests von Cloud-APIs für Haushaltsgeräte haben wir wiederholt gesehen, dass das Ändern der Geräteseriennummer oder -ID im Request Lese- oder Steuerzugriff auf das Gerät eines anderen Haushalts gab. Das Muster wiederholt sich bei Saugrobotern, Bewässerungssteuerungen und Ladegeräten.
• Mehrstufige Abläufe verstecken es. Der Listen-Endpunkt filtert korrekt; der Detail- oder Export-Endpunkt nicht. Jeder Endpunkt, der eine ID entgegennimmt, braucht seine eigene Prüfung.
• Scanner können es nicht finden. Jeder Request ist gültiges HTTP mit gültiger Session. BOLA zu finden braucht zwei Konten, jeden Endpunkt und einen Tester, der IDs systematisch tauscht. Autorisierungstests sind deshalb fester Teil unseres API-Testplans.

Der Fix ist eine serverseitige Autorisierungsprüfung bei jedem Objektzugriff, einmal zentral umgesetzt (eine Policy-Funktion oder ein ORM-Scope, der immer nach Mandant und Besitzer filtert) statt pro Endpunkt, plus automatisierte Tests, die sicherstellen, dass Nutzer A die Objekte von Nutzer B nicht lesen kann.

Häufige Missverständnisse

IDOR ist keine Offenlegung von IDs; eine ID zu zeigen ist in Ordnung, wenn der Server den Zugriff prüft. Der Fehler wird nicht durch Authentifizierung behoben; der Angreifer ist angemeldet. Und er ist kein Problem der Eingabevalidierung: Die ID ist völlig gültig, sie gehört nur jemand anderem.