IDOR
Auch bekannt als: Insecure Direct Object Reference
IDOR (Insecure Direct Object Reference) ist eine Sicherheitslücke, bei der ein eingeloggter Nutzer fremde Daten abrufen kann, indem er einfach eine andere ID in die Anfrage setzt. Die App prüft, DASS jemand eingeloggt ist, aber nicht, ob ihm die Daten GEHÖREN.
Die Lücke in einem Satz: Eingeloggt heißt nicht berechtigt. Nutzer A ruft /api/budgets/123 auf und bekommt das Budget von Nutzer B, weil die API nur den Login prüft, nicht die Eigentümerschaft.
Warum das DER Standardfehler in KI-Code ist
Coding-Agents bauen Logins meist solide, den Eigentums-Check dahinter oft gar nicht. Die Regel „wenn eingeloggt, darfst du lesen" sieht im Code richtig aus und ist es nicht. Richtig wäre: „wenn eingeloggt, darfst du DEINE Daten lesen." Ein Wort Unterschied. Der real dokumentierte Fall dazu (170 betroffene Apps aus einem KI-Coding-Tool, CVE-2025-48757) steht in der FAQ zu Authentifizierung und Autorisierung.
Wie die Lücke entsteht
Die App nimmt eine ID aus der Anfrage (URL, Request-Body) und lädt den Datensatz, ohne zu prüfen, ob der Datensatz dem anfragenden Nutzer gehört. IDs sind oft erratbar (fortlaufende Nummern) oder tauchen in geteilten Links auf. Ein Angreifer braucht kein Hacker-Werkzeug, nur einen Browser.
Die Gegenregel für jeden Coding-Prompt
„Verify the caller OWNS the resource: check ownership against the user id from the session, never against ids from the request body." Diese eine Zeile im Guardrails-Block schließt die Lücke an der Wurzel: Die Eigentümerprüfung läuft gegen die Session-Identität, nicht gegen das, was der Anfragende behauptet.