Fünftausend Apps, die Daten verlieren

Was es ist und warum es zählt

Der Titel des Videos kommt aus den Nachrichten. Laut einer Analyse, über die Axios berichtet hat (Mai 2026), legten von rund 380.000 mit KI-Tools veröffentlichten Apps rund 5.000 sensible Daten offen. Und TechCrunch (September 2026): Die Firma UpGuard hat rund 16.000 Datenbanken auf Supabase mit zugänglichen persönlichen Daten gefunden. Wenn ich solche Nachrichten lese, interessiert mich nur eine Frage: Ist meine dabei? Beim Benutzen der App merkst du es nicht, denn eingeloggt kommen deine Daten so an, wie sie sollen. Du weißt es erst, wenn du es ausprobierst.

Der Mechanismus, kurz gesagt. Viele mit KI gebaute Apps sprechen direkt mit der Datenbank, etwa Supabase, vom Browser oder vom Handy aus. Dafür tragen sie die Adresse des Projekts und einen öffentlichen Schlüssel mit sich, den jeder sehen kann. Das ist in Ordnung: Die Daten schützt nicht der Schlüssel, sondern die Regeln auf der Datenbank. Bei Supabase heißen sie Row Level Security. Fehlen sie, öffnet dieser Schlüssel die Tabellen für alle.

Darüber habe ich schon in der Anleitung PORTA (strikt.fit/porta) geschrieben, mit den Details zu Supabase, Firebase und den zwei Schlüsseln. Hier ist die Version für jetzt sofort: zwei Proben von je einer Minute, der Prompt, der schließt und neu testet, und wie du das Vorher und Nachher liest.

Nur bei deiner eigenen App

Diesen Test machst du bei deiner eigenen App und deiner eigenen Datenbank, mit Testkonten. Nie bei der App von jemand anderem, auch nicht, um zu sehen, ob sie zu den fünftausend gehört: Daten ohne Erlaubnis zu lesen kann eine Straftat sein, auch wenn die Tür offen steht. Wenn du glaubst, dass eine fremde App offen ist, sag es denen, die sie betreiben.

1. Ohne Login

Die erste Probe beantwortet eine Frage: Was sieht jemand, der gar kein Konto hat? Das dauert eine Minute.

1. Öffne deine App in einem Inkognito-Fenster, ohne dich einzuloggen. So hat der Browser deine Sitzung nicht, und du bist ein beliebiger Besucher.
2. Rechtsklick > Untersuchen > Netzwerk (Network), dann lade die Seite neu.
3. Such eine Anfrage, die an .supabase.co geht, und klick sie an. Dort siehst du die Adresse des Projekts und den öffentlichen Schlüssel (publishable, oder „anon“ in älteren Projekten). Es ist normal, ihn zu sehen: Er ist dafür gemacht, in der App zu stehen.

Öffne dann ein Terminal und starte diese Zeile, nur mit diesen zwei Angaben. Setz dein Projekt, deinen Schlüssel und den Namen einer deiner Tabellen ein:

curl "https://DEIN-PROJEKT.supabase.co/rest/v1/TABELLENNAME?select=*" -H "apikey: OEFFENTLICHER_SCHLUESSEL"

Probier sie bei jeder Tabelle mit Daten von Personen aus: Profile, Nachrichten, Bestellungen, E-Mails. Und mach es bei Tabellen, in denen wirklich Daten stehen, denn eine leere Tabelle antwortet [], auch wenn sie offen ist: Schau vorher im Supabase-Dashboard nach. Kommen Zeilen zurück, kann sie jeder lesen. Kommt bei einer vollen Tabelle [] oder ein Berechtigungsfehler zurück, antwortet diese Tabelle Fremden nicht.

2. Als Nutzer A die Daten von B

Die zweite Probe wird am häufigsten ausgelassen. Die Tür kann für alle ohne Login zu sein und für jeden offen, der eingeloggt ist. Noch eine Minute.

1. Leg zwei Testkonten an, A und B.
2. Speichere mit jedem ein paar Daten: ein Profil, eine Notiz, eine Bestellung.
3. Logg dich als A ein und versuch, die Zeilen von B zu öffnen, zum Beispiel indem du die id in der Anfrage oder in der Adresse der Seite änderst.

Wenn du sie siehst, gibt es keine Regeln. Oder es gibt sie, aber sie sagen „wer eingeloggt ist, liest alles“, und das reicht für persönliche Daten nicht: Die richtige Prüfung ist, wem die Zeile gehört.

3. Der Prompt für Claude Code

Wenn du weißt, was offen ist, lässt du es schließen. Öffne Claude Code im Projektordner und füg das hier ein:

Prüf jede Tabelle meiner Supabase-Datenbank: Sag mir, ob Row Level Security aktiv ist und welche Regeln (Policies) sie hat. Wo sie fehlt, aktiviere sie und schreib die Regeln: Jeder Nutzer liest, erstellt, ändert und löscht nur seine eigenen Zeilen; Tabellen, die bewusst öffentlich sind, nur lesend. Pack den geheimen Schlüssel (secret oder service_role) nie in den Code der App. Mach dann den Test noch einmal: ohne Login mit dem öffentlichen Schlüssel und als Nutzer A auf die Zeilen von B. Zeig mir Tabelle für Tabelle das Ergebnis vorher und nachher.

Jeder Teil hat einen Grund. „Liest, erstellt, ändert und löscht“, weil bei Supabase die Regeln für jede Operation geschrieben werden: Wer nur das Lesen schließt, lässt den Rest offen. „Bewusst öffentlich“, weil ein Katalog von allen gelesen werden kann, aber das muss deine Entscheidung sein, kein Zufall. Und „mach den Test noch einmal“, weil du eine Regel prüfst, indem du sie ausprobierst, nicht indem du sie liest.

Claude prüft, was es sehen kann. Wenn die Tabellen im Code des Projekts stehen, zum Beispiel in den Migrationsdateien, findet es sie dort. Wenn du sie von Hand im Supabase-Dashboard angelegt hast, sag ihm, welche es sind, oder mach die zwei Tests von Hand und gib ihm das Ergebnis. Und wenn Claude Code dich um Erlaubnis bittet, einen Befehl auszuführen, lies, was es gleich tun wird, bevor du ja sagst.

Wie du das Vorher und Nachher liest

Das Ergebnis willst du in einer Form, die man auf einen Blick liest. Du kannst dem Prompt „in einer Tabelle wie dieser“ hinzufügen und diese Vorlage einfügen:

Tabelle | RLS vorher | RLS nachher | Ohne Login vorher | Ohne Login nachher | A auf B vorher | A auf B nachher
profile | nein | ja | Zeilen | [] | Zeilen | nichts

Am Ende willst du drei Dinge sehen: Row Level Security auf jeder Tabelle aktiv, keine Zeilen ohne Login außer in den bewusst öffentlichen Tabellen, und A sieht nichts von B. Wenn eine Tabelle nicht so aussieht, frag Claude nach dem Grund, bevor du weitermachst.

Zwei Dinge, die du wissen musst

Lieber zu als offen

Mit aktiver Row Level Security und keiner Regel kommt über den öffentlichen Schlüssel nichts durch. Also lieber zu als offen, dann öffnest du nur, was nötig ist. Wenn nach dem Fix ein Bildschirm nichts mehr lädt, schalte die Sicherheit nicht ab: Es fehlt eine Regel. Lass genau die hinzufügen:

Der Bildschirm [Name] lädt keine Daten mehr, seit du Row Level Security aktiviert hast. Finde heraus, welche Regel fehlt, und füg die engste hinzu, die reicht. Schalte die Sicherheit auf keiner Tabelle ab. Mach dann beide Tests noch einmal, ohne Login und von A auf B.

Der geheime Schlüssel

Der geheime Schlüssel (secret oder service_role) überspringt alle Regeln. Er gehört nur auf den Server: nie in die App, nie auf GitHub. Ist er in der App oder in einem Repository gelandet, tausch ihn sofort im Supabase-Dashboard aus. Ihn aus dem Code zu löschen reicht nicht: Er bleibt in der Historie und bei allen, die ihn schon gesehen haben.

Du nutzt kein Supabase?

Mach denselben Test mit deiner Plattform: ohne Login, dann von A auf B. Die Namen ändern sich, das Prinzip nicht. Bei Firebase zum Beispiel heißen die Regeln Sicherheitsregeln: Worauf du achten musst und den Prompt, um sie zu prüfen, findest du in der Anleitung PORTA.

Häufige Fehler

• Den Test eingeloggt machen. Nimm ein Inkognito-Fenster, sonst siehst du die Daten, weil du es bist.
• Nur eine Tabelle prüfen. Jede Tabelle hat ihre eigenen Regeln: Prüf alle, zuerst die mit Daten von Personen.
• Einem [] von einer leeren Tabelle trauen. Eine leere Tabelle antwortet [], auch wenn sie offen ist: Prüf eine, in der Daten stehen.
• Beim Test ohne Login aufhören. Mach auch den von A auf B: Dort versteckt sich die Regel „wer eingeloggt ist, liest alles“.
• Row Level Security abschalten, wenn ein Bildschirm nicht lädt. Füg die fehlende Regel hinzu und lass den Rest zu.
• Dem Fix vertrauen, ohne neu zu testen. Mach beide Tests noch einmal und schau dir Vorher und Nachher an, Tabelle für Tabelle.

Checkliste

• Test ohne Login, im Inkognito-Fenster, bei jeder Tabelle mit Daten von Personen.
• Test von A auf B mit zwei Testkonten.
• Row Level Security auf jeder Tabelle aktiv, mit Regeln für Lesen, Erstellen, Ändern und Löschen.
• Öffentliche Tabellen nur lesend, und nur bewusst.
• Geheimer Schlüssel nur auf dem Server, nie in der App.
• Beide Tests nach dem Fix wiederholt, mit Vorher und Nachher vor Augen.

Häufige Fragen