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.

Zugriffskontrolle in der Datenbank verankern

Ein besonders robuster Ansatz ist, die Regel „Jeder sieht nur seine eigenen Daten" direkt in der

Datenbank durchzusetzen — etwa mit Row-Level Security in PostgreSQL. Dann schützt die

Datenbank selbst dann, wenn ein Endpunkt die Prüfung vergisst.

Wichtig dabei: Leserechte und Schreibrechte getrennt denken. Dass ein Nutzer seine eigenen

Daten sehen darf, heißt nicht, dass er jede Spalte davon ändern darf — etwa den eigenen

Tarif oder einen Freigabe-Status. Solche Felder sollten nur über geprüfte Server-Funktionen

geändert werden.

Checkliste für Entwicklungsteams

• Prüft jeder Endpunkt, der eine ID entgegennimmt, ob das Objekt dem aktuellen Nutzer gehört?
• Gilt das auch für Ändern und Löschen — nicht nur für das Lesen?
• Sind Rollen (Nutzer, Admin, Mandant) serverseitig hinterlegt und nicht vom Client steuerbar?
• Gibt es automatisierte Tests mit zwei Nutzerkonten, die gegenseitige Zugriffe prüfen?
• Liefern API-Antworten nur die Felder, die der Nutzer wirklich braucht?

Warum IDOR so oft übersehen wird

IDOR-Lücken sind unauffällig: Die Anwendung funktioniert normal, es gibt keine Fehlermeldung und

keinen Absturz. Klassische Scanner erkennen sie kaum, weil dafür verstanden werden muss, wem

ein Datensatz gehört. Genau deshalb lohnt sich ein Test, der die Antworten verschiedener Nutzer

vergleicht.

Häufige Fragen

Reichen zufällige IDs (UUIDs) als Schutz?

Nein. Sie erschweren das Raten, aber IDs tauchen oft in Links, Logs oder API-Antworten auf. Nur

eine echte Berechtigungsprüfung schützt zuverlässig.

Betrifft IDOR nur APIs?

Nein, auch klassische Webseiten, Datei-Downloads und Export-Funktionen sind häufig betroffen.

Wie schnell sollte eine IDOR-Lücke behoben werden?

Da sie oft den Zugriff auf fremde personenbezogene Daten erlaubt, gehört sie meist zu den

dringenden Funden — auch mit Blick auf die DSGVO.