01 — IDOR

1

Was ist IDOR?

IDOR heißt „Insecure Direct Object Reference". Auf Deutsch: Der Server prüft nicht, ob du eine Bestellung sehen darfst – er gibt sie einfach raus, wenn du die ID kennst.

Beispiel: Du bestellst etwas und siehst in der URL /bestellung?id=1001. Was passiert, wenn du 1002 probierst?

2

🎮 Probier's selbst aus

Das ist ein unsicherer Übungs-Shop. Tippe eine ID ein und drück auf „Anzeigen".

⚠ Unsicherer Übungs-Shop
GET /api/order?id=
3

Wie ein Hacker das ausnutzt

Der Angreifer schreibt ein kleines Script, das alle IDs von 1 bis 99999 durchprobiert und die Daten speichert:

hacker-script.sh
for id in {1..99999}; do
  curl "https://shop.de/api/order?id=${id}" \
    >> alle_bestellungen.json
done
In 5 Minuten hat er die komplette Kunden-Datenbank: Namen, Mails, Adressen, Karten-Endungen, Bestellsummen. Im Darknet bringt das 50.000–500.000 €.
4

🔍 Scanne deine echte Seite

Trage deine Domain ein – wir prüfen, ob öffentlich erreichbare APIs Bestell-, Kunden- oder User-Daten leaken.

🔍 Live-Scan: IDOR & Datenleck-APIs

Sucht öffentlich erreichbare Bestell-, Kunden- und User-APIs auf deiner Domain.

5

✅ Wie schützt du dich?

Der Server muss bei JEDER Anfrage prüfen: „Gehört diese Bestellung zu dem User, der sie anfragt?"

server-check (vereinfacht)
// FALSCH ❌
return db.orders.find({ id });

// RICHTIG ✅
return db.orders.find({
  id,
  user_id: aktuellerUser.id  // <-- der Filter!
});
Mit Postgres + RLS (Row-Level Security) erledigt die Datenbank diesen Check automatisch. Selbst wenn du den Filter im Code vergisst, lässt die DB fremde Bestellungen nicht durch.
Selbst-Test: Logge dich auf deiner Seite ein, öffne deine Bestellung, ändere die ID in der URL um eins. Bekommst du fremde Daten → IDOR-Lücke.