lovable security scheitert, weil du keine Policy geschrieben hast

Deine lovable security fühlte sich solide an, weil Nutzer sich anmelden müssen — die Live-Datenbank blieb öffentlich, bis jemand sie mit dem Anon-Key abfragte.

Vorschau-Speichern klappte. Das Dashboard listete Zeilen. Du published und nahm an, die Login-Wand schützt Kundendaten. Tut sie nicht. Der Supabase-Client im Browser bringt einen öffentlichen Anon-Key mit. Ohne Row Level Security reicht der Key, Tabellen über die REST-API zu lesen und zu schreiben. Scraper brauchen deine React-Komponenten nicht.

Keine Policy geschrieben

KI-Builder liefern Auth-UI und CRUD-Screens schnell. Den unsichtbaren SQL-Schritt, der Zeilen an den eingeloggten Nutzer bindet, überspringen sie.

Jeder kann deine Tabellen mit dem Anon-Key listen

DevTools auf der Live-Site öffnen. VITE_SUPABASE_URL und Anon-Key aus dem Bundle kopieren. REST-Endpunkt in neuem Tab oder per curl aufrufen. Kommen Zeilen ohne Session zurück, waren die Daten nie privat.

Inserts funktionieren für Fremde

Spam-Zeilen über Nacht. Eine Tabelle mit INSERT-Rechten und ohne Deny-Policy nimmt anonyme Writes an. Deine App zeigte „deine“ Notizen nur, weil die Abfrage in JavaScript nach User-ID filterte. Die API erzwingt den Filter erst mit Policies.

RLS an, jede Abfrage scheitert

Du hast Row Level Security aktiviert — die App brach. Erwartbar, bis Allow-Policies existieren. Leeres Policy-Set blockiert alles, auch legitime Nutzer. Fix ist nicht RLS aus. Fix ist Regeln schreiben.

Service-Role-Key im Frontend

Im Repo nach service_role suchen. Steht er in Client-Dateien, ist deine lovable security schlechter als keine. Der Key umgeht alle Policies. Sofort in Supabase rotieren und Admin-Ops in Server-Routen legen.

Sicherheit umfasst Policies, Keys und Publish-Einstellungen. Nutze supabase rls für den SQL-Pfad und lovable deploy für die fünf Einstellungen, nach denen der Editor nie gefragt hat.

Warum Lovable lovable security ohne Policies ausliefert

Lovable erzeugt supabase.from('tasks').select('*') und ein Login-Formular in einer Session. Beides wirkt in der Vorschau fertig. Row Level Security lebt im Supabase-SQL-Editor, nicht im Component Tree, den die KI am häufigsten editiert.

Vorschau fühlt sich privat an, weil nur du sie nutzt. Der Anon-Key ist trotzdem öffentlich im Bundle — aber niemand schaut hin. Launch ändert das Publikum. Bots scannen neue Domains innerhalb von Stunden.

Supabase Auth und RLS sind getrennte Schalter. Auth erzeugt Sessions. RLS entscheidet, welche Zeilen eine Session anfassen darf. Die KI verdrahtet Auth, weil Nutzer es sehen. Policies überspringt sie, weil Fehler erst nach Aktivierung kommen und RLS aus „die Demo repariert“.

Tutorials erwähnen „RLS aktivieren“ in einem Satz. Seitenlang geht es um Tailwind und OAuth-Buttons. Du shippst eine schöne Hülle und eine offene Datenbank.

Zusammengeführte Suchintention zu supabase security landet hier: Die Lücke ist keine fehlende Checkbox in Lovable. Die Lücke sind Postgres-Policies, die der Datenbank noch fehlen.

lovable security in Supabase fixen

Tabelle für Tabelle. Erst Nutzerdaten-Tabellen. Referenztabellen mit nur öffentlichen Lesedaten können offen bleiben, wenn du das willst.

1. Tabellen mit Nutzerdaten inventarisieren. Im Supabase Table Editor jede Tabelle mit E-Mails, Nachrichten, Bestellungen oder Profilfeldern listen. Lookup-Tabellen nur überspringen, wenn keine privaten Felder drin sind.
2. RLS auf jeder Tabelle aktivieren. Tabelle öffnen → Settings → Row Level Security aktivieren. Oder alter table public.your_table enable row level security; im SQL-Editor.
3. SELECT-Policy für Eigentümer. Beispiel notes: select erlauben, wo auth.uid() = user_id. Policy-Templates unter Authentication → Policies nutzen, wenn du die UI bevorzugst.
4. INSERT-Policy ergänzen. Inserts nur, wenn auth.uid() = user_id oder die eingefügte Zeile user_id auf den aktuellen Nutzer setzt. Ohne INSERT-Policy scheitern Saves nach RLS-Aktivierung.
5. UPDATE- und DELETE-Policies. Owner-Check für Änderungen und Löschen spiegeln. Öffentliche Lesetabellen brauchen engere Regeln.
6. Mit Anon-Key außerhalb der App testen. curl oder Supabase-REST-Docs nur mit Anon-Key ohne Session-JWT. Fremde Zeilen dürfen nicht zurückkommen.
7. Service Role aus Client-Code entfernen. Lovable-Projekt nach Service-Keys durchsuchen. Aus Frontend-Dateien löschen. Edge Functions oder Server-Routen für Admin-Aufgaben.
8. Republishen und Login-Flows regressionstesten. Als echter Nutzer auf der Live-Site speichern. Zweites Testkonto darf Zeilen des ersten weder in UI noch per API lesen.

Policies sind Code. Wenn möglich in Migrations versionieren, damit Redeploys nicht driften.

Checkliste, bevor du lovable security produktionsreif nennst

• RLS auf jeder Tabelle mit privaten Nutzerdaten aktiv
• SELECT-, INSERT-, UPDATE- und DELETE-Policies passen zum Ownership-Modell
• Anon-Key-only-API-Calls lesen keine fremden Zeilen
• Keine Service Role oder Drittanbieter-Secrets in Frontend-Bundles
• Live-App speichert und lädt korrekt unter Policies
• Policy-SQL dokumentiert oder migriert, nicht nur einmal in der UI geklickt

FAQ

Reicht lovable security, wenn Nutzer sich anmelden müssen?

Nein. Login beweist Identität im Browser. Ohne serverseitige Row Level Security kann jeder mit deinem öffentlichen Anon-Key Tabellen direkt über die Supabase-API abfragen und deine UI-Filter umgehen.

Was ist der erste lovable security Fix nach dem Publish?

Row Level Security auf jeder Tabelle mit Nutzerdaten aktivieren, dann SELECT- und INSERT-Policies an auth.uid() koppeln. Mit dem Anon-Key außerhalb der App testen, ob Zeilen blockiert sind.

Gehört API-Key-Handling zu lovable security?

Teilweise. Den Supabase-Anon-Key als öffentlich behandeln und Daten mit Policies schützen. Service-Role-Keys und Drittanbieter-Secrets dürfen nie in Frontend-Code oder öffentliche Repos.