Datenbankrechte bei Supabase und Firebase: was KI vergisst

Warum die Datenbank aus dem Browser erreichbar ist

Klassische Anwendungen haben einen Server zwischen Browser und Datenbank, der jede Anfrage prüft. Supabase und Firebase lassen diesen Server weg. Die Oberfläche bekommt eine Adresse und einen öffentlichen Schlüssel und fragt die Datenbank direkt. Das macht sie bei Lovable, Bolt und vielen anderen Werkzeugen so beliebt.

Der öffentliche Schlüssel ist dabei kein Geheimnis, er steht im Browser-Code. Die Sicherheit hängt vollständig an den Regeln, die festlegen, welche Zeilen ein Aufrufer sehen und ändern darf.

Supabase: Row Level Security

In Supabase wird Row Level Security, kurz RLS, pro Tabelle eingeschaltet. Ist RLS aus, kann jeder mit dem öffentlichen Schlüssel die ganze Tabelle lesen und je nach Einstellung auch ändern. Ist RLS an, aber ohne Regel, sieht niemand etwas. Erst die Regeln, die Policies, öffnen gezielt.

Drei Fehler tauchen in KI-generierten Projekten immer wieder auf:

RLS fehlt bei einzelnen Tabellen, meist bei solchen, die später dazugekommen sind. 2025 wurde bei einer grösseren Zahl öffentlicher Lovable-Apps genau das nachgewiesen und als CVE-2025-48757 erfasst.
Die Regel prüft nur, ob jemand angemeldet ist, nicht, ob ihm die Zeile gehört. Dann sieht jeder registrierte Nutzer die Daten aller anderen. Richtig ist eine Bedingung wie auth.uid() = user_id.
Die Regel ist zum Testen offen und wurde nie geschlossen, erkennbar an using (true).

Der Security Advisor im Supabase-Dashboard warnt vor Tabellen ohne RLS. Er erkennt aber nicht, ob eine vorhandene Regel inhaltlich richtig ist.

Firebase: Security Rules

Bei Firebase übernehmen die Security Rules dieselbe Aufgabe für Firestore, die Realtime Database und Storage. Wer ein Projekt im Testmodus anlegt, bekommt Regeln, die für eine begrenzte Zeit allen Zugriff erlauben. Danach wird alles gesperrt, und die naheliegende Reparatur ist eine Regel, die wieder alles öffnet.

Ebenso häufig: allow read, write: if request.auth != null;. Das heisst: Jeder Angemeldete darf alles. Richtig ist, auch hier die Nutzerkennung mit dem Besitzer des Dokuments zu vergleichen. Der Rules Playground in der Firebase-Konsole zeigt, was eine Regel für einen bestimmten Aufruf erlaubt.

So prüfen Sie es selbst

Listen Sie alle Tabellen bzw. Sammlungen auf. Prüfen Sie für jede, ob Regeln aktiv sind.
Lesen Sie jede Regel und beantworten Sie in einem Satz: Wer darf welche Zeilen lesen, wer darf schreiben?
Legen Sie zwei Testkonten an. Melden Sie sich mit Konto A an und versuchen Sie, über die Oberfläche und über veränderte Adressen Daten von Konto B zu sehen.
Öffnen Sie ein privates Fenster ohne Anmeldung und beobachten Sie in den Entwicklerwerkzeugen, ob Anfragen an die Datenbank Daten zurückliefern.
Prüfen Sie, ob der geheime Schlüssel, bei Supabase der service_role- bzw. secret Key, irgendwo im Browser-Code steht. Er umgeht alle Regeln. Mehr im Artikel API-Schlüssel im Frontend.

Regeln nicht der KI allein überlassen

Lassen Sie die KI ruhig Regeln vorschlagen. Prüfen Sie aber jede selbst nach dem Satz aus Schritt 2. Und prüfen Sie nach jeder grösseren Änderung erneut: Wenn die KI eine Fehlermeldung „permission denied“ beheben soll, ist die schnellste Lösung oft, die Regel zu lockern.

Bevor Sie damit live gehen

Ihre Lösung läuft. Diese Punkte sollten Sie prüfen, bevor echte Daten daran hängen:

Ist für jede Tabelle Row Level Security bzw. eine Security Rule aktiv?
Prüfen die Regeln, wem eine Zeile gehört, oder nur, ob jemand angemeldet ist?
Steht der geheime Datenbankschlüssel irgendwo im Browser-Code?

Sie wollen sicher sein? Das Vibe-Code-Review prüft genau diese Grundlagen. Mehr zum Review →

Lieber selbst anfangen? Die kostenlose Schnellprüfung aus dem Vibecode-Testing-Kit zeigt Ihnen, wo Sie stehen. Zur Schnellprüfung →