Sicherheitsprüfung für Lovable- und Supabase-Apps

Das Grundproblem: Die Oberfläche schützt nichts

Bei klassischen Webanwendungen sitzt ein eigenes Backend zwischen Nutzer und Datenbank. Bei den meisten Lovable-Projekten nicht: Das React-Frontend spricht mit dem Supabase-Client und einem öffentlichen Schlüssel direkt die Datenbank-API an. Das ist ein legitimes Architekturmuster – aber jede Regel, die nur in der Oberfläche umgesetzt ist, lässt sich mit den Entwicklertools des Browsers oder einem einfachen HTTP-Aufruf umgehen. Ein ausgeblendeter Admin-Button ist keine Zugriffskontrolle.

Die fünf Prüfbereiche

Row Level Security im Detail

Hier liegen die meisten und folgenreichsten Fehler. Prüfen Sie insbesondere:

• ob RLS auf allen Tabellen im Schema public aktiv ist – auch auf solchen, die per SQL-Migration nachträglich entstanden sind,
• ob Update- und Insert-Policies eine with check-Bedingung haben,
• ob Nutzer ihre eigene Rolle ändern können, etwa über eine Spalte is_admin im eigenen Profil,
• ob Views mit security_invoker = true angelegt sind, da sie sonst mit den Rechten des Eigentümers laufen und RLS umgehen,
• welche Funktionen mit security definer laufen und was sie preisgeben.

Der Security Advisor im Supabase-Dashboard weist auf Tabellen ohne RLS und weitere typische Schwachstellen hin. Er ist ein guter Anfang, ersetzt aber nicht die fachliche Frage, wer welche Zeilen sehen darf. Grundlagen erklärt die Supabase-Dokumentation zu Row Level Security.

Schlüssel, Edge Functions und Dateien

Der Anon- oder Publishable-Key darf öffentlich sein, er landet zwangsläufig im JavaScript-Bundle. Der Service-Role- oder Secret-Key umgeht RLS vollständig. Durchsuchen Sie deshalb das gebaute Bundle und die gesamte Git-Historie, nicht nur den aktuellen Code. Schlüssel von Zahlungsanbietern oder KI-Diensten gehören ausschließlich in Edge Functions.

Bei Edge Functions gilt: Die standardmäßige JWT-Prüfung bestätigt nur, dass ein gültiges Token mitgeschickt wurde – und der öffentliche Anon-Key ist selbst ein gültiges Token. Ermitteln Sie in der Funktion den tatsächlichen Nutzer und prüfen Sie dessen Rechte. Dateien wie Rechnungen, Ausweise oder Nutzer-Uploads gehören in private Buckets mit Policies auf storage.objects.

Damit es sicher bleibt

Eine einmalige Prüfung veraltet mit dem nächsten Prompt. Jede neue Tabelle, die Lovable anlegt, braucht wieder passende Policies. Bewährt haben sich:

• Datenbankänderungen ausschließlich als Migrationen im Git-Repository,
• automatisierte Tests für Policies, etwa mit pgTAP, die bei jeder Änderung laufen,
• eine kurze Checkliste für jede neue Tabelle und jeden neuen Bucket.

Datenschutz nicht vergessen

Für Anwendungen mit Nutzern in der EU lohnt ein Blick auf die Region des Supabase-Projekts, den Auftragsverarbeitungsvertrag und die Frage, welche Daten überhaupt gespeichert werden müssen. Wird eine Datenpanne bekannt, sieht die DSGVO in der Regel eine Meldung an die Aufsichtsbehörde binnen 72 Stunden vor. Eine saubere RLS-Konfiguration ist deshalb nicht nur Technik, sondern Risikovorsorge. Dies ersetzt keine Rechtsberatung.

So unterstützt jocapps

OnlineAppCreator ist unser ISO-zertifiziertes B2B- und B2G-Delivery-Team in Deutschland. Es prüft und härtet KI-gebaute Prototypen für den Produktivbetrieb: RLS-Policies, Schlüsselverwaltung, Login, Storage und Edge Functions, auf Wunsch mit langfristiger Betreuung per SLA. Ergänzend liefert UXreviewer.io innerhalb von 10 Werktagen einen UX-Report mit kommentierten Screenshots, Mockups und konkreten Verbesserungsideen – hilfreich, damit strengere Registrierungs- und Rechteabläufe für Nutzer verständlich bleiben. Mehr zum Leistungsbereich Prototyp zu Produktion oder im kostenlosen 30-minütigen Erstgespräch über den Terminplaner.