Lovable-Datenleck: So prüft ihr eure Supabase-Daten

Was die Untersuchung gefunden hat

Crissy Field hat zusammen mit dem Handelsblatt 159.041 Lovable-Projekte untersucht. 34.545 davon nutzten Supabase. Bei 7.403 von 24.664 näher untersuchten Seiten ließen sich ohne Anmeldung Tabellen mit E-Mail-Adressen abrufen. Die Autoren weisen darauf hin, dass das keine bestätigte Leckquote ist. Die Größenordnung zeigt trotzdem, wie oft Zugriffsregeln fehlen oder zu viel erlauben.

Warum das passiert

Eure App spricht mit Supabase über einen öffentlichen Schlüssel (anon key oder publishable key). Er steht im Code, den jeder Browser lädt, und das ist so vorgesehen. Wer welche Zeilen lesen darf, regelt allein Row Level Security (RLS) mit ihren Policies. Fehlt RLS oder erlaubt eine Policy allen alles, kann jeder mit diesem Schlüssel die Tabelle abfragen.

Die Falle: RLS ist aktiv und die Daten sind trotzdem offen

Für diesen Ratgeber haben wir in Lovable eine kleine App gebaut, die eine Kontaktliste ohne Login anzeigt. Lovable hat dafür RLS eingeschaltet und zugleich eine Policy angelegt, die jedem das Lesen erlaubt (using (true) für anon). Im Supabase-Dashboard wirkte die Tabelle damit geschützt, abrufbar war sie trotzdem. Lovable hat getan, worum wir gebeten hatten: Die Daten sollten ohne Login sichtbar sein. Ob das bei euren Daten gewollt ist, entscheidet ihr.

So prüft ihr es selbst: 1. Tabellen ohne RLS finden

Im Supabase-Dashboard unter SQL Editor:

Steht bei rowsecurity der Wert false, gibt es für diese Tabelle keine Zugriffsregeln.

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

2. Policies finden, die allen alles erlauben

Kritisch sind Einträge mit anon oder public in roles und true in qual oder with_check.

select tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public';

3. Von außen testen

Nur bei eurer eigenen App. Kommt [] zurück, ist die Tabelle leer oder geschützt. Kommt ein Datensatz zurück, ist sie ohne Login lesbar.

curl "https://EUER-PROJEKT.supabase.co/rest/v1/TABELLE?select=*&limit=1" \
  -H "apikey: EUER_OEFFENTLICHER_SCHLUESSEL"

So behebt ihr es: RLS aktivieren

RLS für jede Tabelle im Schema public aktivieren:

alter table public.kontakte enable row level security;

Offene Policies durch eine engere ersetzen

Entfernt offene Policies und ersetzt sie durch eine engere, etwa „jeder sieht nur seine eigenen Zeilen“ (setzt eine Spalte user_id voraus):

Prompt für Lovable: „Prüfe alle Tabellen auf Row Level Security. Gib Daten, die nicht öffentlich sein sollen, nur angemeldeten Nutzern und nur deren eigene Zeilen frei. Entferne Policies mit using (true), außer für Inhalte, die wirklich öffentlich sein sollen.“

Waren personenbezogene Daten offen, prüft, ob sie schon abgerufen wurden. Bei einer Datenschutzverletzung kann eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden nötig sein (Art. 33 DSGVO). Holt dazu rechtlichen Rat ein. Dieser Ratgeber ist keine Rechtsberatung.

drop policy "Alle dürfen Kontakte lesen" on public.kontakte;
create policy "Eigene Kontakte lesen" on public.kontakte
  for select to authenticated
  using ((select auth.uid()) = user_id);

Typische Fehler

Diese Fehler kommen häufig vor:

• RLS nur bei einigen Tabellen aktiviert, später angelegte Tabellen vergessen.
• Eine Policy mit using (true) zum Testen angelegt und nie wieder entfernt.
• Den service_role-Schlüssel im Frontend verwendet. Er umgeht RLS vollständig (siehe Ratgeber zum Supabase-Key).
• Storage-Buckets als öffentlich markiert, obwohl darin Dateien von Nutzern liegen.

Häufige Fragen