IDOR‑Test für Copy‑Link‑Ansichts‑Schwachstellen in Ihrer App

Wie „Copy‑Link‑Viewing“ in echten Apps aussieht

„Copy‑Link‑Viewing“ tritt auf, wenn jemand eine Seite in Ihrer App allein durch Einfügen eines Links öffnen kann, obwohl er diesen Datensatz eigentlich nicht sehen darf. Das erscheint häufig bei Rechnungen, Projekten, Support‑Tickets, geteilten Dokumenten und manchmal bei Admin‑Bildschirmen mit einer „Link kopieren“-Schaltfläche.

Das Risiko liegt nicht in der Teilen‑Funktion selbst. Gefährlich ist, dass die App Daten allein anhand der URL (z. B. einer ID) lädt, ohne stets zu prüfen, ob der aktuelle Nutzer Zugriff haben darf.

Ein typisches Beispiel: Ein Kunde kopiert den Link zu seiner Rechnung und schickt ihn an seinen Buchhalter. Der Buchhalter klickt ihn an, während er mit seinem eigenen Konto angemeldet ist (oder gar nicht angemeldet) — und sieht trotzdem die Rechnung. Schlimmer: wenn die URL wie /invoice/1042 aussieht, führt das Ändern auf /invoice/1043 zur Rechnung eines anderen Kunden.

Viele Teams fühlen sich sicher, weil der Link „zufällig aussieht“ (eine lange Zeichenkette). Zufälligkeit ist aber keine Berechtigung. Prüft der Server nicht bei jedem Zugriff die Berechtigung, kann ein zufällig wirkender Link trotzdem durch Teilen, Weiterleiten, Browser‑History, Screenshots oder das Wiederverwenden einer alten Nachricht Daten offenlegen.

Nutzer melden das oft als „komisches“ Verhalten wie:

• „Ich habe auf einen Link geklickt und den Namen oder die E‑Mail einer anderen Person gesehen.“
• „Ich kann einen alten Link in einem privaten Fenster öffnen und er funktioniert immer noch.“
• „Mein Kollege kann meinen Datensatz sehen, obwohl er nicht hinzugefügt wurde.“
• „Der Support hat nach einem Link gefragt — jetzt kann jeder mit dem Link das Ticket sehen."

Diese Anleitung führt Sie durch einen einfachen Zwei‑Konten‑IDOR‑Test, um unsicheren direkten Objektzugriff ohne Code‑Lesen zu finden. Sie lernen, was Sie ausprobieren sollten, was als Leak gilt und wie Sie Beweise erfassen, die ein Entwickler schnell beheben kann.

IDOR ohne Sicherheitsjargon erklärt

IDOR steht für unsicheren direkten Objektzugriff. Einfach gesagt heißt das: Sie können eine ID in einem Link (oder einer Anfrage) ändern und sehen die Daten einer anderen Person. Die App liefert ein echtes Objekt (Projekt, Rechnung, Nachricht oder Datei) hauptsächlich anhand eines Identifikators, ohne richtig zu prüfen, ob Sie dieses Objekt sehen dürfen.

Ein typisches Muster: Sie öffnen eine Seite und die URL enthält eine Item‑ID. Ersetzen Sie diese ID durch eine andere und die App zeigt den Eintrag einer anderen Person — das ist ein Autorisierungsfehler.

Die Unterscheidung ist einfach:

• Authentifizierung beantwortet: „Sind Sie eingeloggt?“
• Autorisierung beantwortet: „Darf der Nutzer auf dieses konkrete Objekt zugreifen?“

Viele Apps stimmen beim ersten Punkt, scheitern aber beim zweiten. Eingeloggt zu sein beweist lediglich, dass Sie ein Nutzer sind — nicht, dass Sie jeden Datensatz sehen dürfen.

Ein nützliches Denkmodell:

• Objekt: das, worauf Sie zugreifen möchten (Dokument, Bestellung, Ticket)
• Besitzer: der Nutzer oder das Team, dem das Objekt gehört
• Berechtigungsprüfung: die App muss jedes Mal bestätigen, dass der aktuelle Nutzer Zugriff auf genau dieses Objekt hat

Fehlt diese Prüfung oder ist sie zu locker, wird aus „Link kopieren“ versehentliche Datenoffenlegung.

Wo sich IDOR‑Bugs am häufigsten verstecken

IDOR‑Probleme tauchen nicht auf Marketing‑Seiten auf, sondern in den „echten Arbeitsbereichen“ der App, wo Datensätze per ID geladen werden und Aktionen wie Herunterladen oder Exportieren existieren.

Seiten, die einen einzelnen Datensatz per ID laden

Diese sind häufig, weil die URL oft genau auf einen Datensatz abbildet:

• Rechnungen, Belege, Angebote, Reports, signierte PDFs
• Projekte, Aufgaben, Tickets, Notizen, Kommentare
• Profile, Abrechnungsseiten, Einstellungen, Team‑ oder Workspace‑Admin‑Screens
• Anhänge, Exporte, Bild-/Datei‑Downloads
• „Share“‑Seiten, die öffentlich wirken, aber privat gemeint sind

Ein schneller Geruchstest: Wenn sich die Seite völlig ändert, wenn Sie nur eine Zahl oder ein Token in der Adresse ändern, könnte sie der ID zu sehr vertrauen.

Hintergrund‑APIs, die trotzdem leaken

Viele Apps laden Daten per API im Hintergrund. Manchmal ist der Bildschirm geschützt, aber der API‑Endpunkt nicht.

Beispiel: Die Ticket‑Seite ist gesperrt, doch ein Endpunkt wie „getTicket?id=123“ liefert Ticket‑Details an jeden angemeldeten Nutzer.

Wenn Sie eine schnell generierte AI‑App (Lovable, Bolt, v0, Cursor, Replit) geerbt haben, seien Sie hier besonders vorsichtig. Zugriffskontrollen sind über Routen oft inkonsistent, besonders bei Downloads, Exporten und „nebenbei“‑Endpunkten.

Testvorbereitung: Zwei‑Konten‑Test sicher einrichten

Sie simulieren, was ein echter Nutzer mit einem geteilten Link tun würde. Bleiben Sie sicher: normale Nutzerkonten, Testdaten, getrennte Browser‑Sitzungen.

1. Erstellen Sie zwei normale Nutzer: Konto A und Konto B. Geben Sie keinem Admin‑Rechte oder einer „alles sehen“ Rolle.
2. Falls Ihre App Workspaces, Orgs oder Teams kennt, setzen Sie A und B in unterschiedliche Gruppen.
3. Legen Sie unter Konto A 1–2 eindeutige Test‑Objekte an (z. B. ein Dokument mit Titel „IDOR Test - A“ oder eine Dummy‑Rechnung über 1 $). Verwenden Sie Fake‑Daten.
4. Notieren Sie, was passieren sollte, z. B.: „Nur der Besitzer kann ansehen“ vs. „Jeder mit dem Link kann ansehen, aber nicht bearbeiten.“
5. Trennen Sie die Sessions, damit Logins sich nicht vermischen:

• Konto A im normalen Browserfenster
• Konto B im Inkognito/privaten Fenster oder in einem separaten Browserprofil

Schritt für Schritt: Copy‑Link‑Viewing‑Test

Der Test ist einfach: Konto A kann einen Eintrag sehen, dann versucht Konto B, genau den kopierten Link zu öffnen.

1. Melden Sie sich als Konto A an und öffnen Sie ein Zielobjekt (Rechnung, Projekt, Ticket, Dokument, Nachrichtenverlauf).
2. Kopieren Sie die vollständige URL aus der Adresszeile. Achten Sie auf alles, was wie ein Identifikator aussieht (Nummer, UUID‑ähnliche Zeichenkette, Slug).
3. In der separaten Sitzung melden Sie sich als Konto B an.
4. Fügen Sie den exakten Link ein und laden Sie die Seite.
5. Falls etwas geladen wird, versuchen Sie eine kleine Änderung, indem Sie nur den Identifikator ändern und neu laden.

Wiederholen Sie das Muster auf „Seitentüren“, die oft mehr leaken als der Hauptbildschirm. Tun Sie nichts Zerstörerisches.

• Wenn es eine Edit‑Route gibt, sehen Sie, ob Konto B das Bearbeitungsformular laden kann.
• Gibt es eine Download/Export‑Aktion (PDF, CSV, Anhang), prüfen Sie, ob sie eine Datei zurückgibt.
• Wenn die Seite überhaupt lädt, achten Sie auf zusätzliche Daten (Namen, E‑Mails, Beträge, interne Notizen).

Wenn Konto B irgendetwas Reales sehen kann, selbst eine Vorschau oder Metadaten, behandeln Sie das als Autorisierungsfehler.

Ergebnisse interpretieren (und was als Leak zählt)

Suchen Sie nicht nur nach einem dramatischen „Ich sehe alles“‑Fehler. Viele reale Probleme geben nur genug preis, um Schaden anzurichten.

Welche Ergebnisse was bedeuten

Vergleichen Sie, was Konto B mit dem Link von Konto A sehen kann:

• Volle Zugriffsrechte: B sieht denselben Inhalt wie A. Deutlicher Leak.
• Teilweise Daten: B kann die Seite nicht normal nutzen, sieht aber Namen, Beträge, Nachrichten, Anhänge. Ebenfalls Leak.
• Nur Metadaten: B erkennt, dass der Datensatz existiert (Titel, Besitzer, Zeitstempel). Ebenfalls Leak.
• Korrekte Verweigerung: B wird konsequent blockiert und es erscheinen keine privaten Daten.

Ein „404 Not Found“ ist nicht immer sicher. Wenn manche IDs 404 liefern, andere einen anderen Fehler, eine andere Seite oder merklich andere Ladezeiten, könnten Sie trotzdem verraten, welche Datensätze existieren.

Auf stille Leaks achten

Manche Apps verbergen die UI, laden die Daten aber trotzdem im Hintergrund. Die Seite wirkt leer, doch die Antwort (oder eine heruntergeladene Datei) enthält private Informationen.

Achten Sie auch auf Berechtigungs‑Mix‑Ups: Das Anzeigen ist blockiert, aber Konto B kann trotzdem editieren, löschen, herunterladen oder exportieren.

Testen Sie sowohl Desktop als auch Mobil — mobile Ansichten treffen manchmal andere Endpunkte.

Beweise erfassen, mit denen ein Entwickler arbeiten kann

Ein guter Bericht spart Stunden.

Sammeln Sie:

• Die exakte verwendete URL (voller Pfad und sichtbare ID)
• Datum/Uhrzeit, Umgebung (Produktion vs. Staging) und Browser/Gerät
• Nachweise von beiden Konten (Screenshots oder eine kurze Aufnahme)

Bei Screenshots sollten Sie etwas einblenden, das deutlich macht, welches Konto angemeldet ist (Profil‑Icon, E‑Mail, Kontoname). Andernfalls kommt oft „nicht reproduzierbar“ zurück.

Formulieren Sie die Regel, die durchgesetzt sein sollte, in einfacher Sprache:

• „Konto B darf nur seine eigenen Rechnungen sehen.“
• „Nur eingeladene Projektmitglieder dürfen dieses Dokument sehen.“
• „Nur Absender und Empfänger dürfen diesen Thread lesen.“

Listen Sie dann genau auf, was offengelegt wurde (Namen, E‑Mails, Adressen, Beträge, Notizen, Anhänge). Verwenden Sie Testdaten, die harmlos sind.

Schnelle Checkliste: 5‑Minuten‑IDOR‑Scan

Verwenden Sie zwei normale Konten (keine Admins). Wählen Sie einige Datentypen, die privat zwischen Nutzern bleiben sollten.

• Vergewissern Sie sich, dass beide Konten dieselbe Rolle und Berechtigungen haben.
• Testen Sie mindestens drei Objekttypen (z. B. Dokument, hochgeladene Datei, Abrechnungsseite).
• Testen Sie für jeden Typ mehr als „Ansehen“ (Bearbeiten/Form laden, Herunterladen/Exportieren).
• Machen Sie eine „erratbare“ Änderung (z. B. /items/104 → /items/105 oder einen lesbaren Slug tauschen).
• Prüfen Sie das Verhalten bei Zugriff verweigert: sowohl unautorisierter Zugriff als auch ungültige IDs sollten sicher und konsistent fehlschlagen.

Testen Sie außerdem im ausgeloggten Zustand in einem frischen privaten Fenster. Seiten, die privat sein sollen, dürfen nur aufgrund einer URL keine Inhalte anzeigen.

Häufige Testfehler, die den Bug übersehen

Teams testen das oft einmal, sehen nichts Offensichtliches und hören auf. Ein paar Muster verbergen den Fehler regelmäßig.

• Die zwei Konten liegen im selben Workspace oder derselben Org (gerade Cross‑Org‑Szenarien führen oft zum Fehler).
• Share‑Links (die öffentlich sein sollen) mit privaten Links verwechseln.
• Annehmen, dass lange IDs sicher sind. Fehlt die serverseitige Prüfung, genügt jede gültige ID.
• Nur prüfen, was die UI zeigt — nicht Downloads/Exporte oder Hintergrunddaten.
• Nach einer Seite aufhören; ähnliche Bildschirme werden oft mit anderen Regeln implementiert.

Praktische Herangehensweise: testen Sie die Detailseite, den Download/Export‑Endpunkt und alle zugehörigen „Activity/Comments“‑Views für dasselbe Objekt.

Ein einfaches Beispiel zum Vergleich mit Ihrer App

Stellen Sie sich ein Kundenportal vor, in dem jeder Kunde seine Rechnungen sehen kann. Unter Konto A öffnen Sie eine Rechnung und klicken „Link kopieren“.

Wechseln Sie zu Konto B (ein anderer Kunde) und fügen Sie dieselbe Rechnungs‑URL ein.

Kann Konto B Summen, Positionen, Kundennamen sehen oder die PDF herunterladen, ist das eine Copy‑Link‑Viewing‑Schwachstelle. Die App vertraut dem Link (oder der darin enthaltenen ID) mehr als der Berechtigung des angemeldeten Nutzers.

Was stattdessen passieren sollte: Die App verweigert den Zugriff, es erfolgt eine Weiterleitung oder eine Login‑Aufforderung. Wenn Ihr Produkt Teilen unterstützt, sollte der Link nur funktionieren, wenn er explizit geteilt wurde — und das Teilen muss widerrufbar sein.

Beim internen Reporting bleiben Sie konkret:

• Auswirkung: „Jeder eingeloggte Nutzer kann durch Einfügen eines kopierten Links die Rechnungen anderer Kunden sehen.“
• Betroffene Bereiche: „Rechnungs‑Detailseite und PDF‑Download.“
• Repro: „Als A einloggen, Link kopieren, als B einloggen, Link einfügen, Daten/PDF werden geladen.“
• Beispieldaten: „Rechnungsbetrag $X, Rechnungsname, PDF‑Inhalt.“

Wie man es richtig behebt und was als Nächstes zu tun ist

Der Fix, der wirklich funktioniert

Wenn Ihr Zwei‑Konten‑Check Copy‑Link‑Viewing zeigt, sitzt die Lösung fast nie in der UI. Sie liegt auf dem Server: Jedes Mal, wenn die App einen Datensatz liest oder ändert, muss sie bestätigen, dass der angemeldete Nutzer Zugriff auf genau dieses Objekt hat.

Verlassen Sie sich nicht auf versteckte Buttons, clientseitige Prüfungen oder „nicht erratbare“ IDs. Kann ein Nutzer einen Link einfügen, eine ID ändern und die Daten eines anderen sehen, fehlt die Berechtigungsprüfung oder sie ist unvollständig.

Folgendes sollte bei jedem verwundbaren Endpunkt durchgesetzt werden:

• Authentifizierung verlangen, wenn die Seite nicht öffentlich sein soll
• Autorisierung für genau dieses Objekt prüfen (Besitzer, Workspace‑Mitglied, Rolle)
• Standard: verweigern
• Dieselbe Regel auf Lesen, Schreiben, Exporte und Downloads anwenden
• Abgelehnte Versuche protokollieren, um Missbrauch aufzudecken

Was als Nächstes zu tun ist

Nachdem Änderungen live sind, führen Sie denselben Zwei‑Konten‑Test gegen dieselben Seiten und Downloads wie zuvor erneut durch. Einen Route zu fixen lässt oft eine „Seitentür“ offen.

Bei schnell generierten Projekten (z. B. Lovable, Bolt, v0, Cursor, Replit) planen Sie extra Zeit ein — solche Codebasen haben häufig mehrere Routen, die dieselben Daten berühren.

Wenn Sie Hilfe beim Bestimmen des Umfangs und beim sauberen Patchen der Zugriffskontrolle wünschen, spezialisiert sich FixMyMess (fixmymess.ai) auf das Diagnostizieren und Reparieren AI‑generierter Codebasen, einschließlich Autorisierungsfehlern, Sicherheits‑Härtung und Deployment‑Vorbereitung.