Teil 2 – Praktische Beispiele für IDOR

Sep. 12, 2025

—

von

Wo IDORs am häufigsten auftreten

IDOR-Schwachstellen verstecken sich oft an Stellen, die auf den ersten Blick völlig harmlos wirken. Typische Angriffsflächen sind:

URLs: Parameter wie ?id=123 oder ?user=42.
APIs: REST- oder GraphQL-Endpunkte, die Objekte über IDs ansprechen.
Formularfelder: Besonders „hidden fields“, die IDs enthalten.
Cookies oder Tokens: Werte, die zwar existieren, aber nicht geprüft werden.

Der gemeinsame Nenner: Der Server vertraut dem Wert, den der Client mitschickt, anstatt selbst zu prüfen, ob der Nutzer auf dieses Objekt zugreifen darf.

Ein Szenario aus dem Alltag

Stell dir vor, du nutzt eine E-Learning-Plattform. Dort kannst du Rechnungen herunterladen. Die URL sieht so aus:

https://learn.example.com/invoice?id=5501

Als eingeloggter Nutzer erhältst du damit deine eigene Rechnung. Doch was passiert, wenn du die Zahl von 5501 auf 5502 änderst?

https://learn.example.com/invoice?id=5502

Wenn die Anwendung nicht prüft, ob Rechnung 5502 auch wirklich dir gehört, siehst du plötzlich die Rechnung einer fremden Person. Darauf könnten stehen:

Vollständiger Name
Rechnungsadresse
Gebuchte Leistungen
Zahlungsinformationen

Damit hat der Angreifer nicht nur persönliche Daten, sondern eventuell auch sensible Finanzinformationen.

Beispiel in einer API

Auch moderne Apps mit APIs sind betroffen. Nehmen wir eine Fitness-App:

GET /api/v1/workouts/2001 HTTP/1.1
Host: fitapp.example.com
Authorization: Bearer eyJhbGciOi...

Die App zeigt dir damit dein eigenes Training. Aber wenn du neugierig bist und 2001 auf 2002 änderst, könnte die API dir die Daten eines anderen Nutzers liefern: Ort, Dauer, verbrannte Kalorien.

Das klingt harmlos, aber stell dir vor, es geht um medizinische Daten in einer Gesundheits-App oder um Finanztransaktionen in einer Banking-App. Der gleiche Mechanismus kann extrem kritisch sein.

IDOR durch Formular-Manipulation

Auch in Formularen lauert die Gefahr. Ein Profil-Update-Formular könnte so aussehen:

<form action="/updateProfile" method="POST">
  <input type="hidden" name="userid" value="42">
  <input type="text" name="email" value="alice@example.com">
  <button type="submit">Speichern</button>
</form>

Mit den Entwicklertools im Browser lässt sich das versteckte Feld userid leicht manipulieren. Ändert man den Wert auf 43, könnte die Anwendung plötzlich das Profil eines anderen Nutzers überschreiben.

Noch gravierender wird es, wenn Felder wie role=admin in Formularen versteckt sind und der Server diese Werte unkritisch übernimmt. Ein Angreifer könnte sich so selbst zum Administrator machen.

Ein Blick auf reale Vorfälle

IDOR-Schwachstellen sind keine Theorie. In den letzten Jahren tauchten sie regelmäßig in Bug-Bounty-Programmen und Sicherheitsmeldungen auf. Beispiele:

In einer großen Social-Media-App konnten Nutzer durch Manipulation von IDs private Fotos fremder Accounts abrufen.
Ein Ticket-System für Events erlaubte es, fremde Eintrittskarten herunterzuladen, indem man die Ticket-ID in der URL anpasste.
Bei einer Bank-App war es möglich, durch Änderung der Überweisungs-ID Details von Transaktionen anderer Kunden zu sehen.

Solche Vorfälle zeigen: Schon kleine Fehler in der Zugriffskontrolle können große Konsequenzen haben.

Warum diese Beispiele so gefährlich sind

Das Tückische: All diese Szenarien benötigen kein spezielles Hacking-Tool. Jeder, der ein wenig mit URLs oder Formularen experimentiert, kann so etwas entdecken. Genau deshalb sind IDOR-Schwachstellen besonders kritisch und tauchen regelmäßig in den OWASP Top 10 auf.

Für Angreifer bedeutet das: Mit minimalem Aufwand lassen sich sensible Daten abgreifen oder sogar fremde Konten übernehmen. Für Unternehmen bedeutet es: Datenpannen, Bußgelder und Vertrauensverlust.