Teil 4 – Wie man sich gegen IDOR schützt

Sep. 12, 2025

—

von

Das Grundprinzip: Autorisierung auf Objektebene

Die wichtigste Verteidigung gegen IDOR ist, dass der Server nicht nur prüft, ob ein Nutzer eingeloggt ist, sondern auch, ob er wirklich berechtigt ist, auf genau dieses Objekt zuzugreifen.
Ein Login allein reicht nicht. Ein Nutzer kann authentifiziert sein und trotzdem fremde Daten anfragen. Darum braucht es eine zusätzliche Autorisierungsprüfung:

Darf Nutzer A Profil 42 sehen?
Darf Nutzer B Bestellung 123 bearbeiten?

Nur wenn die Antwort „ja“ lautet, darf der Server die Daten zurückgeben.

Autorisierung niemals im Client

Eine goldene Regel: Vertraue niemals auf Client-Daten.
Alles, was im Browser, in einer App oder im Request-Body steckt, kann manipuliert werden. Wenn die Logik lautet:

if (userid === sessionUserId) {
  showProfile();
}

dann ist das unsicher, weil der Client das Feld userid jederzeit ändern kann.
Die Autorisierung muss serverseitig passieren.

Beispiel für einen sicheren Zugriff

Angenommen, eine API soll das Profil eines Nutzers zurückgeben:

// unsicher
app.get('/api/user/:id', (req, res) => {
  const user = db.findUser(req.params.id);
  res.json(user);
});

Hier bekommt jeder Nutzer jedes Profil, solange er die ID kennt.
Sicherer ist:

// sicher
app.get('/api/user/:id', (req, res) => {
  const user = db.findUser(req.params.id);
  if (user.id !== req.authenticatedUser.id) {
    return res.status(403).send('Access denied');
  }
  res.json(user);
});

Damit wird geprüft, ob der angefragte Datensatz wirklich zum eingeloggten Nutzer gehört.

Opaque IDs statt einfacher Zähler

Viele IDORs entstehen, weil IDs einfach vorhersehbar sind (1001, 1002, 1003). Eine Verbesserung ist der Einsatz von opaque IDs:

UUIDs (z. B. 550e8400-e29b-41d4-a716-446655440000)
Hashwerte oder zufällige Tokens

Dadurch wird es für Angreifer schwieriger, IDs einfach zu erraten. Wichtig: Das ersetzt keine Autorisierung, macht Angriffe aber deutlich aufwendiger.

Rollen- und Rechtekonzepte nutzen

Eine saubere Rollen- und Rechteverwaltung hilft, IDORs zu verhindern. Beispiele:

Normale Nutzer dürfen nur ihre eigenen Daten sehen.
Admins dürfen zusätzliche Funktionen ausführen.
Support-Mitarbeiter sehen bestimmte Daten, aber nicht alles.

Viele Frameworks bringen fertige Lösungen mit, z. B.:

Spring Security (Java) mit objektbasierter Zugriffskontrolle
Laravel Policies (PHP) für Autorisierungslogik
Django Permissions (Python)

Wenn möglich, sollte man diese Mechanismen konsequent einsetzen, statt eigene Lösungen zu basteln.

Logging und Monitoring

Auch wenn eine Anwendung sicher gebaut ist, lohnt sich ein Blick auf die Logs. Verdächtige Muster wie „ein Nutzer ruft 200 verschiedene IDs in kurzer Zeit ab“ deuten oft auf IDOR-Versuche hin.
Mit Monitoring-Tools (z. B. SIEM-Systemen) lassen sich solche Auffälligkeiten erkennen und automatisch melden.

Typische Fehler in der Praxis

Nur auf Login prüfen: „Wenn der Nutzer eingeloggt ist, darf er alles sehen.“ → Falsch.
Client-Validierung nutzen: „Das Feld userid kommt aus einem versteckten Input, das passt schon.“ → Unsicher.
Opaque IDs als einzige Lösung: „Wir nutzen UUIDs, das reicht.“ → Unvollständig ohne Autorisierungslogik.