Kunde sieht fremde Daten: was zuerst zu tun ist

Was es bedeutet, wenn ein Kunde fremde Daten sieht

Wenn ein Kunde Daten eines anderen sehen kann, behandle es als dringenden Vorfall. Auch wenn es wie ein UI‑Fehler aussieht, kann es private Informationen offenbaren, Vertrauen schnell zerstören und rechtliche bzw. vertragliche Risiken erzeugen (Datenschutzgesetze, NDAs, Enterprise‑Vereinbarungen).

„Fremde Daten“ meint alle Informationen, die zu einem anderen Nutzer, Account oder Unternehmen (Mandant) gehören. Das kann an offensichtlichen Stellen auftreten oder in kleinen Details, die trotzdem Personen identifizieren.

Beispiele sind die Daten eines anderen Nutzers wie:

• Name, E‑Mail, Adresse oder Profilangaben
• Rechnungen, Zahlungsstatus, Abo‑Plan oder Abrechnungshistorie
• Nachrichten, Support‑Tickets oder interne Notizen
• Dateien, Dokumente oder Exporte (CSV/PDF)
• Nur‑Admin‑Ansichten wie Nutzerlisten, Audit‑Logs oder API‑Keys

Wichtige Unterscheidung:

• Ein Datenisolation‑Bug ist ein Produktfehler, der Daten an den falschen Mandanten zurückgibt oder anzeigt.
• Ein Breach bedeutet, dass eine unbefugte Partei tatsächlich auf Daten zugegriffen hat (du hast Beweise oder starke Indizien dafür).

Anfangs weißt du das oft nicht. Handle so, als sei die Exposition real, bis du das Gegenteil beweisen kannst.

Die praktischen Ziele bleiben gleich:

1. Die Exposition schnell stoppen (Containment).
2. Den Umfang herausfinden (wer hat was gesehen, wie oft, und seit wann).
3. Die Ursache sicher beheben.
4. Klar kommunizieren, während ihr arbeitet, und anschließend erklären, was sich geändert hat.

Sofortiges Containment in den ersten 15 Minuten

Behandle das als laufenden Sicherheitsvorfall, nicht als normales Bug‑Ticket. Deine erste Aufgabe ist, weitere Exposition zu verhindern, auch wenn du die Ursache noch nicht kennst.

Beginne damit, den Bericht zu bestätigen und ein Incident‑Log zu eröffnen. Notiere die genaue Uhrzeit des Eingangs, wer gemeldet hat, was gesehen wurde (wörtlich) und etwaige Screenshots. Zeitstempel jede Aktion und Entscheidung von da an.

Benenne eine*n Incident‑Owner. Diese Person muss nicht selbst den Fix schreiben, sollte aber Entscheidungen koordinieren, Notizen führen und Updates verschicken, damit das Team nicht in verschiedene Richtungen zieht.

Reduziere die Blast‑Radius schnell:

• Wenn du ein bestimmtes Feature (Admin‑Ansicht, Suche, Exporte, „Letzte Aktivitäten“, Shared‑Inbox) vermutest, deaktiviere es oder blockiere den Endpoint.
• Kannst du es nicht schnell isolieren, versetze die App in Read‑Only‑ oder Wartungsmodus, damit Kunden keine neuen Requests auslösen, die Daten offenbaren könnten.

Während du das Problem einhegst, friere riskante Änderungen ein. Pausiere Deploys, Migrationen und Hintergrundjobs, die Daten überschreiben. Vermeide „Quick‑Fixes“ direkt in Produktion, bis das Bild klarer ist.

Eine einfache Containment‑Checkliste:

• Incident‑Log mit Zeitstempeln und Details des Melders eröffnen
• Eine*n Incident‑Owner (und Backup) bestimmen
• Das verdächtige Feature/Endpoint oder betroffene Rollen deaktivieren
• Read‑Only oder Wartungsmodus nutzen, falls der Umfang unklar ist
• Deploys und Migrationen pausieren, bis Containment bestätigt ist

Bestätigen und den Umfang ermitteln, ohne die Exposition zu verbreitern

Du musst den Bericht schnell bestätigen, ohne den Kunden zu bitten, weitere sensible Daten zu senden.

Bitte um die kleinste Menge an Schritten, die zum Problem geführt haben. Frage nach Handlungen, nicht nach vertraulichen Inhalten. Nützliche Details sind Zeitpunkt, welche Seite angezeigt wurde und welches Workspace/Account genutzt wurde.

Hilfreiche Fragen:

• Auf welcher genauen Seite oder bei welcher Aktion wurden die fremden Daten angezeigt?
• War es einmalig oder passiert es bei jedem Refresh?
• Haben sie sich kürzlich ausgeloggt und wieder eingeloggt oder zwischen Accounts/Workspaces gewechselt?
• Tritt es in einem anderen Browser oder mobil ebenfalls auf?
• Wie viel sah falsch aus (ein Eintrag, viele Zeilen, eine ganze Account‑Ansicht)?

Reproduziere sicher. Nutze einen brandneuen Test‑Mandanten und einen least‑privileged Testnutzer (keinen Admin). Falls du zwei Mandanten brauchst, erstelle zwei saubere Testkonten, damit du nicht mit echten Kundendaten arbeitest.

Prüfe dann das Verhalten:

• Hard Refresh
• Neue Session (Inkognito)
• Zweites Gerät

Wenn das Problem nur nach einem Deploy, nach Account‑Wechseln oder nur für eine bestimmte Rolle auftritt, deutet das oft auf Caching, Session‑Handling oder Authorization‑Grenzen hin.

Behandle es als bestätigte Exposition, wenn du es reproduzieren kannst oder Logs cross‑tenant Reads zeigen (auch wenn du noch nicht reproduzieren kannst). Behalte hohe Dringlichkeit, wenn es ein Einzelfall ohne Belege ist, bis du ihn ausschließen kannst.

Was du dokumentieren solltest, damit du es beheben und erklären kannst

Deine Notizen werden zur Basis für den Fix und die spätere Erklärung. Erfasse den Bericht genau, bevor irgendjemand ihn umformuliert.

Halte fest:

• Wer gemeldet hat und wie man die Person erreicht
• Wann es bemerkt wurde
• Welche Ansicht/Feature genutzt wurde
• Die genaue Beschreibung dessen, was falsch aussah

Bitte um Belege mit Bedacht. Wenn ein Kunde einen Screenshot teilt, bitte ihn, Namen, E‑Mails, Adressen, Zahlungsdaten und alles nicht zur Reproduktion Nötige zu verpixeln. Lege Dateien in einem eingeschränkten Ordner ab und notiere, wer Zugriff hat.

Minimale technische Details, die du erfassen solltest

Du willst genug Identifikatoren, um den Pfad nachzuspielen, ohne mehr sensible Daten zu sammeln als nötig.

Erfasse:

• Zeitstempel (mit Zeitzone): Eingang des Berichts, erste Repro, Containment und jede Änderung
• Reporting‑User‑ID und Tenant/Workspace‑ID (und die andere Tenant‑ID, falls identifizierbar)
• Request‑IDs/Correlation‑IDs und Session‑Identifier
• Betroffene Endpoints/Seiten, Filter und ungewöhnliche Query‑Parameter
• App‑Version oder Commit‑Hash und Zeitpunkt des letzten Deploys

Hole früh Log‑Snapshots, weil manche Systeme rotieren. Sichere relevante Auth‑Logs, Gateway/Load‑Balancer‑Logs, App‑Logs und Datenbank‑Query‑Logs für das Zeitfenster. Notiere, woher sie stammen und wie lange das Quellsystem sie aufbewahrt.

Führe eine fortlaufende Timeline der Containment‑Maßnahmen (Feature‑Flags, deaktivierte Zugriffe, Cache‑Purge, Rollback‑Start) und wer welchen Schritt gemacht hat.

Schnelle Triagierung: Häufige Ursachen zuerst testen

Die meisten Cross‑Tenant‑Lecks stammen aus einer kleinen Menge von Fehlerursachen. Beginne mit den einfachsten und arbeite dich zu den subtileren vor.

Eine straffe Reihenfolge von Checks

1. Authorisierung und Mandantenfilter

Suche nach Reads, die Datensätze per id laden, ohne Besitz zu prüfen, oder Endpoints, die vergessen, Tenant/Workspace‑Filter anzuwenden. Achte auf IDOR‑artige Pfade wie /invoices/123, bei denen der Server nicht verifiziert, dass der Datensatz zum aktuellen Mandanten gehört.

2. Session‑Mix‑Ups

Prüfe, ob Cookies und Tokens korrekt scoped sind (Domain, Path, Umgebung). Achte auf geteilte Demo‑Accounts, wiederverwendete Signier‑Keys über Umgebungen hinweg oder einen Proxy, der Auth‑Header entfernt.

3. Caching‑Fehler

Untersuche CDN‑ und serverseitige Cache‑Header. Ein fehlendes Vary auf Auth‑Headern oder das Cachen von HTML/API‑Antworten, die nicht geteilt werden dürfen, kann dazu führen, dass Nutzer A eine Antwort von Nutzer B erhält. Prüfe auch den Client‑State: veralteter LocalStorage kann nach Logout alte Daten anzeigen.

4. Datenbank‑Query‑Bugs

Überprüfe jüngste Query‑Änderungen, Joins und Default‑Scopes. Häufige Probleme sind Joins, die die Mandantenbedingung verlieren, Soft‑gelöschte Datensätze, die wieder auftauchen, oder Fallback‑Queries, wenn ein Filter leer ist.

5. Background‑Jobs und Anhänge

Stelle sicher, dass Exporte, PDFs, E‑Mails und Webhooks aus dem richtigen Mandanten‑Kontext gebaut werden. Queue‑Worker laufen oft ohne dieselben request‑scope Prüfungen.

Nach jedem Check beantworte eine Frage: Kommen die falschen Daten vom Server, oder zeigt die UI das Falsche? Das Erfassen des API‑Response‑Bodys und der Header macht das meist deutlich.

Kurzfristige Maßnahmen, während der Codefix gebaut wird

Dein Ziel ist, neue Exposition schnell zu stoppen, noch bevor die komplette Root‑Cause behoben ist.

Zugriff reduzieren, während ihr untersucht

Wenn du Session‑ oder Token‑Mix‑Ups vermutest, stoppt ein erzwungener sauberer Login oft die Verbreitung.

Gängige kurzfristige Maßnahmen:

• Aktive Sessions entziehen und erneute Authentifizierung verlangen (für alle Nutzer oder zumindest betroffene Mandanten)
• Account‑Switching, Impersonation und „View as“‑Admin‑Funktionen temporär deaktivieren
• Exporte und Downloads (CSV, PDF) pausieren und Admin‑Screens mit vielen Einträgen einschränken
• Sensitive Seiten hinter ein temporäres Wartungs‑Gate legen, wenn Isolation nicht zuverlässig ist
• Rate‑Limits hinzufügen, um massenhaftes Abrufen zu erschweren, während ihr untersucht

Informiere Support über die Änderungen, damit sie erklären können, warum Nutzer ausgeloggt wurden oder Exporte pausiert sind.

Temporäre Schutzmaßnahmen hinzufügen

Füge serverseitige Prüfungen ein, die schwer zu umgehen sind. Validiert Mandantenbesitz für jede Anfrage, nicht nur beim ersten Seitenaufruf.

Ziehe außerdem in Betracht, Caching für sensitive Endpoints und Seiten (inklusive CDN/Reverse‑Proxy) zu deaktivieren. Kannst du es nicht komplett ausschalten, verkürze die Cache‑Dauer und stelle sicher, dass der Cache‑Key Tenant‑ und Nutzerkontext enthält.

Und: Fail‑Closed. Wenn die Tenant‑ID fehlt, uneindeutig oder nicht übereinstimmend ist, gib einen Fehler zurück, statt zu raten.

Wie man mit dem meldenden Kunden kommuniziert

Antworte schnell, auch wenn du noch keine Antworten hast. Schweigen wirkt wie Ignorieren eines ernsten Problems.

Nutze eine ruhige, direkte Nachricht: du hast den Bericht erhalten, behandelst ihn dringend und unternimmst Schritte, um weitere Exposition zu verhindern, während du untersuchst. Streit, Spekulation oder Schuldzuweisungen gegenüber ihrer Umgebung vermeiden.

Bitte um die minimal nötigen Details, die euch helfen, das Problem nachzustellen:

• Welche Seite oder welches Feature zeigte die falschen Daten (und was wurde erwartet)
• Wann es passiert ist (mit Zeitzone)
• Welches Workspace/Account sie verwendet haben
• Ob es nach Refresh, Logout oder im privaten Fenster erneut auftritt
• Einen Screenshot mit verpixelten sensitiven Feldern (nur wenn sicher möglich)

Lege eine Aktualisierungsfrequenz fest, die du einhalten kannst. Ein brauchbarer Standard ist: „Wir melden uns alle 2 bis 4 Stunden, auch wenn wir noch untersuchen."

Eine knappe Nachricht, die sich wiederverwenden lässt:

„Danke, dass Sie das gemeldet haben. Wir untersuchen das dringend und haben Containment‑Maßnahmen eingeleitet, um weitere Exposition zu verhindern. Bitte teilen Sie uns die Seiten-/Feature‑Bezeichnung, ungefähre Zeit und das Workspace mit. Wir senden ein Update innerhalb von 2 Stunden und dann alle paar Stunden, bis das Problem gelöst ist.“

Sobald ihr eine Minderung oder einen Fix habt, folgt eine verständliche Nachricht:

• Was ihr gefunden habt
• Was ihr geändert oder temporär deaktiviert habt
• Welche Daten sichtbar gewesen sein könnten und für welchen Zeitraum (so weit bekannt)
• Was ihr als Nächstes tut (Monitoring, zusätzliche Prüfungen)

Wie intern und gegenüber anderen Kunden kommunizieren

Wähle eine*n Message‑Owner (oft der Incident‑Lead). Leitet Updates über diese Person, damit Support, Sales und Engineering keine unterschiedlichen Geschichten erzählen.

Nutze in jedem Update eine einfache Timeline, sodass man schnell scannen kann: entdeckt, contained, in Fix‑Phase, verifiziert. Nutze eine Zeitzone.

Sei explizit, was ihr wisst vs. was noch bestätigt werden muss. Rate nicht. Verweise auf Belege (Logs, Screenshots, spezifische Endpoints) und nenne, was ihr als Nächstes überprüft.

Wenn ihr mögliche Auswirkungen beschreibt, benennt die konkreten Datentypen, nicht nur vage „personenbezogene Daten“. Beispiele: Account‑E‑Mail, Name, Firmenname, Rechnungspdf, letzte 4 Stellen einer Karte, Lieferadresse, Support‑Ticket‑Text, hochgeladene Dateien. Sage „keine Passwörter wurden offengelegt“ nur, wenn du Belege dafür hast.

Eine einfache interne Update‑Vorlage:

• Status: entdeckt um [Zeit], contained um [Zeit], Fix läuft, Verifizierung läuft
• Was passiert ist: 1–2 Sätze
• Potentiell betroffene Daten: konkrete Felder und Bildschirme
• Was wir wissen / was wir prüfen: zwei kurze Zeilen
• Nächstes Update: eine konkrete Uhrzeit

Bevor ihr andere Kunden informiert, stimmt euch auf einen klaren Auslösepunkt (z. B. bestätigter Cross‑Tenant‑Zugriff, bestätigte Exporte/Downloads, oder Beleg, dass es länger als eine Session andauerte).

Beispiel‑Szenario: Mandantendaten nach einem Deploy vermischt

Ein Support‑Ticket kommt freitags nachmittags: ein Kunde sagt, auf der Rechnungsseite habe er die Rechnungsnummer, den Betrag und die Rechnungsadresse einer anderen Firma gesehen.

Das Team behandelt es als potentiellen Datenexpositionsvorfall und enthält den Vorfall, bevor es debuggt:

• Sie deaktivieren die Rechnungsseite per Feature‑Flag.
• Sie schalten die Cache‑Schicht für Rechnungsantworten aus, um mismatched cached data zu vermeiden.
• Sie entziehen aktive Sessions für Accounts, die kürzlich Abrechnungen genutzt haben, und erzwingen Re‑Auth.

Nach dem Containment reproduzieren sie das Problem mit zwei Test‑Mandanten und prüfen die Zugriffslogs für den Invoice‑Endpoint. Das Muster ist klar: Eine API‑Route liefert falsche Tenant‑IDs zurück, und das trat erst nach dem letzten Deploy auf.

Ein Diff der letzten Änderung zeigt die Root‑Cause. Bei einem Refactor wurde Query‑Logik in einen Helper verschoben, der keine tenantId mehr erforderte, sodass ein Endpoint die Tenant‑Filterung nicht mehr anwendete.

Sie liefern einen Hotfix, der:

• explizite Tenant‑Authorisierungsprüfungen am Endpoint hinzufügt
• Tests einführt, die dieselbe Anfrage über mehrere Accounts laufen lassen, um Isolation zu bestätigen
• bei fehlendem Tenant‑Kontext „closed“ fehlschlägt

Anschließend informieren sie den Kunden in klarer Sprache: was passiert ist, welche Daten sichtbar gewesen sein könnten, was das Problem gestoppt hat und was einen Wiederholung verhindert.

Häufige Fehler, die Datenexposition verschlimmern

Kleine Entscheidungen in der ersten Stunde können die Auswirkungen vergrößern und die Bereinigung erschweren.

Fehler 1: Viele Änderungen ohne klare Dokumentation

Unter Druck probiert man gern „ein paar Sachen“, bis das Problem weg ist. Dann verliert ihr die Spur dessen, was wirklich geholfen hat, und könnt Beweise zerstören, die später gebraucht werden.

Schreibt jede Änderung auf: was geändert wurde, wer es gemacht hat, wann und warum. Behandle Rollbacks, Feature‑Flag‑Toggles und Konfig‑Änderungen als formelle Schritte.

Fehler 2: Sensible Daten während der Untersuchung weiterreichen

Support‑Teams fragen manchmal nach Screenshots, Screen‑Recordings oder Exportdateien. Das kann private Daten weiter verbreiten.

Bitte um das Minimum: Zeitstempel, Seitenname und die Schritte. Wenn ein Screenshot unvermeidbar ist, bitte den Kunden, Namen, E‑Mails, Tokens und alles Unnötige zu verpixeln.

Weitere Fehler, die vermieden werden sollten:

• Öffentliches Posten von Updates, bevor Grundlagen bestätigt sind (wer betroffen ist, welche Daten, ob Zugriff echt war)
• Annehmen, es sei „nur die UI“, ohne zu prüfen, ob das Backend Mandantenprüfungen erzwingt
• Testen des Fixes nur mit einem Admin‑Account und dadurch andere Rollen oder API‑Pfade übersehen
• Den ersten Bericht als einzigen Fall behandeln statt Logs auf ähnliche Zugriffe zu prüfen

Eine übliche Falle: Ein Frontend‑Patch verhindert, dass gemischte Daten angezeigt werden, also erklärt jemand das Problem für gelöst. Später zeigt sich, dass die API weiterhin Cross‑Tenant‑Reads per Direkteingabe zulässt. Bestätige immer Server‑seitige Isolation über Rollen und Mandanten hinweg.

Kurze Checkliste und praktische nächste Schritte

Behandle „Ich sehe die Daten eines anderen Kunden“ als Notfall. Stoppe zuerst weitere Exposition, sammle dann genug Fakten, um es zu beheben und klar zu erklären.

Eine praktische Checkliste, in der Reihenfolge:

• Contain (jetzt): Feature/Endpoint deaktivieren, riskantes Caching abschalten und Deploys/Konfig‑Änderungen pausieren, bis Containment bestätigt ist.
• Scope (nächste 30–60 Minuten): Sicher reproduzieren (Test‑Accounts), betroffene Bildschirme/APIs identifizieren und das Zeitfenster schätzen (seit letztem Deploy/Migration/Konfig‑Änderung).
• Beweise sichern: Request‑IDs, Zeitstempel, User‑IDs, Tenant‑IDs und relevante Logs speichern. Screenshots intern redigieren, bevor sie geteilt werden.
• Sicher patchen: Explizite Tenant‑Checks hinzufügen, Cache‑Keys fixen und automatisierte Tests, die fehlschlagen, wenn Mandantengrenzen überschritten werden.
• Kommunizieren: Den Bericht bestätigen, eine Einhaltezeit für Updates setzen und dokumentieren, was passiert ist, wer betroffen war und was geändert wurde.

Führe von Minute eins ein Incident‑Dokument. Halte fest, wer es bemerkt hat, wie du es eingegrenzt hast, welche Logs das zeigten und welcher Commit oder welche Konfig‑Änderung es behoben hat.

Wenn du mit einem KI‑generierten Prototype arbeitest, dessen Auth, Mandantenprüfungen und Caching unter Druck schwer zu vertrauen sind, kann FixMyMess (fixmymess.ai) ein kostenloses Code‑Audit durchführen, die Isolation‑Lücke lokalisieren und beim Reparieren und Härten der App helfen – die meisten Projekte sind innerhalb von 48–72 Stunden abgeschlossen.