IDOR verstehen: die unterschätzte API-Schwachstelle

Was ist ein IDOR?

Eine Insecure Direct Object Reference (IDOR) entsteht, wenn eine Anwendung den Zugriff auf ein

Objekt allein über einen vom Nutzer kontrollierbaren Bezeichner steuert — etwa eine ID in der URL —

ohne zu prüfen, ob das Objekt dem Aufrufer überhaupt gehört.

Ein klassisches Beispiel:

GET /api/users/1042   → eigene Daten
GET /api/users/1043   → fremde Daten (HTTP 200!)

Wenn der zweite Aufruf fremde Nutzerdaten zurückgibt, liegt ein IDOR vor. Durch simples Hochzählen

lässt sich oft die gesamte Datenbank exfiltrieren.

Warum Scanner sie übersehen

IDOR ist ein Logik-Problem, kein Signatur-Problem. Ein Scanner sieht bei /api/users/1043 ein

HTTP 200 und eine valide JSON-Antwort — technisch "alles in Ordnung". Ob die Antwort *fremde* Daten

enthält, kann er ohne Verständnis des Kontexts nicht beurteilen.

Dazu kommt: IDOR sitzt fast immer hinter dem Login. Ein unauthentifizierter Scan erreicht die

verwundbaren Endpunkte gar nicht erst.

So findet agentschmitz IDOR

Zwei Bausteine sind nötig — und agentschmitz bringt beide mit:

• Authentifiziertes Testen: Der Agent meldet sich als echter Nutzer an und testet hinter der

Anmeldung.

• Hypothesen-getriebenes Vorgehen: Der Spezialist erkennt einen ID-basierten Endpunkt, variiert

die ID gezielt und vergleicht die Antworten — gehören sie zu einem anderen Nutzer, ist der Fund

bestätigt.

Schutz

• Autorisierung serverseitig pro Objekt prüfen: "Gehört dieses Objekt dem aktuellen Nutzer?"
• Schwer ratbare Bezeichner (UUIDs) sind sinnvoll, aber kein Ersatz für echte Zugriffskontrolle.
• Zugriffsentscheidungen zentralisieren statt in jedem Endpunkt neu zu erfinden.