‹ Alle Artikel

DSGVO Art. 17: Warum euer Löschpfad wahrscheinlich lückenhaft ist

Ein Scan über eine echte Firestore-App fand rund 140 Collections, die beim Account-Löschen liegen blieben. So findet man sie.

Die Datenschutzerklärung steht. Der „Account löschen"-Knopf funktioniert. Der Nutzer klickt, sein Konto verschwindet, alles gut.

Nur: Sind seine Daten wirklich weg? Bei einer App mit vielen Datenbank-Collections lautet die Antwort erschreckend oft nein. Nicht aus bösem Willen — sondern weil Feature und Löschpfad von zwei verschiedenen Personen zu zwei verschiedenen Zeitpunkten gebaut wurden.

Wie die Lücke entsteht

Der Ablauf ist immer derselbe, und er ist völlig unspektakulär:

  1. Ein neues Feature wird gebaut. Es schreibt Nutzerdaten in eine neue Collection.
  2. Das Feature funktioniert. Tests grün. Ausgeliefert.
  3. Der Löschpfad wurde nicht angefasst — er kennt die neue Collection schlicht nicht.

Niemand hat einen Fehler gemacht. Es hat nur niemand daran gedacht. Und weil nichts kaputtgeht, fällt es auch nicht auf: Der Löschknopf tut ja etwas. Er tut nur nicht genug.

Art. 17 DSGVO — das Recht auf Löschung — verlangt nicht, dass der Account verschwindet. Es verlangt, dass die personenbezogenen Daten verschwinden. Das ist ein Unterschied, den der Code kennen muss.

Was ein Scan über eine echte App fand

Wir haben unsere eigene App geprüft — systematisch, nicht stichprobenartig. Das Ergebnis war ernüchternd: rund 140 Collections, die Nutzerdaten schreiben, ohne dass der Löschpfad sie mitnimmt.

In einem Projekt, das von Anfang an mit Datenschutz im Blick gebaut wurde. Von jemandem, der weiß, was Art. 17 verlangt. Die Lücke entsteht nicht aus Unkenntnis, sondern aus Wachstum: Jedes neue Feature ist eine neue Gelegenheit, den Löschpfad zu vergessen.

Warum man das nicht manuell prüfen kann

Der naheliegende Ansatz — „schauen wir mal durch" — skaliert nicht. Bei über 200.000 Zeilen Code ist Durchschauen kein Prüfen, sondern Hoffen. Man braucht zwei Listen und einen Abgleich:

  • Liste A: Alle Stellen, die Nutzerdaten schreiben — welche Collection, welches Feature.
  • Liste B: Alles, was der Löschpfad tatsächlich anfasst.
  • Die Differenz ist die Lücke.

Genau das machen wir automatisiert, vor jedem Release. Der Scan ist stumpf und zuverlässig — er vergisst nichts, weil er nicht müde wird.

Ein Befund ist ein Prüfauftrag, kein Urteil

Wichtig, sonst erzeugt so ein Scan nur Rauschen: Ein statischer Scan sieht nicht alles. Wenn eine serverseitige Funktion beim Löschen aufräumt, taucht das im App-Code nicht auf — der Scan meldet trotzdem eine Lücke.

Deshalb behandeln wir jeden Treffer als „das muss jemand anschauen", nicht als„das ist kaputt". Ein Werkzeug, das Fehlalarme als Fakten verkauft, wird nach zwei Wochen ignoriert — und dann nützt es niemandem mehr.

Der zweite blinde Fleck: Auskunft und Export

Art. 17 bekommt die Aufmerksamkeit. Art. 15 und Art. 20 — Auskunftsrecht und Datenübertragbarkeit — werden oft ganz vergessen. Ein Nutzer darf nicht nur verlangen, dass seine Daten gelöscht werden. Er darf auch verlangen, sie zu bekommen.

Wenn diese Anfrage kommt und es keinen Export-Pfad gibt, wird aus einer Ein-Klick-Sache ein manueller Datenbank-Ausflug. Deshalb prüfen wir im selben Durchgang mit, ob der Pfad überhaupt existiert.

Was Sie mitnehmen sollten

Wenn Ihre App mehr als eine Handvoll Datenbank-Collections hat, ist Ihr Löschpfad wahrscheinlich lückenhaft. Nicht weil schlampig gearbeitet wurde — sondern weil die Lücke beim Wachsen entsteht und sich nicht bemerkbar macht.

Die Prüfung ist einmal Arbeit und danach automatisch. Die Alternative ist, es darauf ankommen zu lassen — bis jemand fragt.

Projekt im Kopf?

Wenn Sie an ähnlichen Problemen sitzen — wir bauen Software, die solche Fallen umgeht.

✉ andreklein99@gmx.de