Lovable-App absichern: der Zwei-Konten-Test vor dem Launch

Deine App läuft, die ersten Menschen legen Konten an, und plötzlich kommt die Frage: Kann eigentlich jemand die Daten der anderen sehen? Genau das fragt jemand in einer Diskussion auf Reddit. Die Person hat ohne Programmierkenntnisse eine App mit Lovable gebaut, die nach zwei Monaten rund 300 Konten hat, lässt fast täglich den Sicherheits-Scan laufen und sucht nach Tests, die weder viel Geld noch Fachwissen kosten.

Die Antworten sind erstaunlich einig. Und die gute Nachricht: Den wichtigsten Test schaffst du ohne Code selbst.

Das eigentliche Risiko ist selten ein Hacker

Mehrere Kommentatoren betonen dasselbe: Bei Apps, die mit KI gebaut sind, steckt hinter Datenlecks meist kein raffinierter Angriff, sondern eine offene Datenbank. Die meisten Lovable-Apps nutzen Supabase. Die typische Lücke dort: Ein angemeldeter Nutzer kann die Zeilen eines anderen lesen.

Wichtig zu verstehen: Der Supabase anon key in deiner App ist dafür gedacht, öffentlich zu sein. Das Problem ist eine Tabelle ohne Row Level Security (RLS) oder eine Policy, die zu großzügig ist. Supabase beschreibt eine Policy wie eine zusätzliche Bedingung, die an jede Abfrage einer Tabelle angehängt wird. Fehlt sie oder lautet sie sinngemäß „jeder darf alles lesen“, liegt die Tabelle offen.

Ein häufiger Fehler in generierten Apps, wie ein Kommentator schreibt: Die Policy prüft nur „ist angemeldet“ statt „ist Besitzer“. Dann ist jeder eingeloggte Nutzer ein potenzieller Leser aller Daten.

Warum der Scan nicht reicht

Den Scan regelmäßig laufen zu lassen, ist eine gute Gewohnheit. Aber er prüft den Code, den er sieht. Ob die Regeln hinter jeder Tabelle zu deiner App passen, kann er nicht beurteilen, nur ob es überhaupt welche gibt. Das ist eine Frage der Regeln, nicht des Codes.

Dazu kommt ein tückischer Effekt: Viele KI-Tools filtern die Daten im Frontend nach der Nutzer-ID. Auf dem Bildschirm sieht Nutzer B also nur seine eigenen Einträge. Ist RLS aber aus oder die Policy offen, kann B im Browser die Datenbank direkt abfragen und bekommt alle Zeilen aller Nutzer zurück. Wer nur durch die Oberfläche klickt, findet diese Lücke nie.

Der Zwei-Konten-Test Schritt für Schritt

In einem zweiten Reddit-Beitrag beschreibt ein Anbieter von Sicherheitschecks einen Test in sechs Schritten. Du brauchst nur zwei Konten mit E-Mail-Adressen, die dir gehören:

1. Leg Konto A und Konto B an, eines im normalen Browserfenster, eines im privaten.
2. Erstelle als A von allem, was deine App speichert, einen Eintrag: eine Notiz, ein Projekt, einen Upload. Öffne die Entwicklertools, Reiter „Network“, und such die Anfrage an /rest/v1/.... Notiere Tabelle und ID.
3. Öffne als B die Seite von A mit A’s ID. Erwartet: eine leere Seite oder ein Fehler.
4. Kopiere als B eine ähnliche /rest/v1/-Anfrage („Copy as fetch“), füge sie in die Konsole ein und setz A’s ID ein. Erwartet: ein leeres Ergebnis.
5. Melde dich ab und schick die Anfrage erneut. Private Tabellen liefern nichts oder einen Berechtigungsfehler.
6. Vergiss die Dateien nicht: Öffne als B die Datei-URL von A. Private Dateien sollten nur über einen signierten Link erreichbar sein.

Teste nur Apps, die dir gehören, und nur mit eigenen Testkonten. Wiederhole den Test für jede Tabelle und jeden Speicher-Bucket.

Wenn etwas durchrutscht

Findest du ein Leck, kannst du Lovable gezielt beauftragen: Es soll dir die aktuellen Policies der betroffenen Tabelle zeigen und sie so umschreiben, dass jeder Nutzer nur Zeilen lesen, anlegen, ändern und löschen darf, die ihm selbst gehören. Bitte ausdrücklich darum, erst das SQL und den passenden Test zu zeigen und nichts auszuführen, bevor du zustimmst.

Supabase selbst empfiehlt, für jede Operation eine eigene Policy zu schreiben. Beim Ändern sorgt eine zusätzliche Prüfung (with check) dafür, dass niemand einen Eintrag einfach einem anderen Nutzer zuschiebt.

Ein paar weitere Prüfungen aus der Diskussion, alle ohne Code:

• Security Advisor öffnen. Im Supabase-Dashboard markiert er Tabellen ohne RLS. Alles mit „Table publicly accessible“ zuerst beheben.
• Keine geheimen Schlüssel im Browser. Nur der öffentliche Schlüssel gehört ins Frontend. Laut Supabase umgeht ein Secret Key oder der ältere service_role key RLS komplett und darf nie im Browser landen.
• Rollen nicht in User-Metadaten. Die kann ein angemeldeter Nutzer laut Supabase selbst ändern. Lass dir von Lovable auflisten, welche Spalten ein Nutzer an seinen eigenen Zeilen ändern darf. Stehen dort role, is_admin, plan oder credits, kann sich jemand selbst zum Admin machen.
• Views im Blick behalten. Laut Supabase umgehen Views RLS standardmäßig und brauchen eigene Aufmerksamkeit.
• Backups prüfen. Ein fehlerhafter KI-Edit, der eine Tabelle leert, ist nach Ansicht eines Kommentators wahrscheinlicher als ein Angriff.

Welche Rolle Lovables eigene Zertifikate für deine App spielen, steht in Lovable ist zertifiziert – ist deine App es damit auch?.

Was das für deinen Launch bedeutet

Absichern ist kein Extra nach dem Launch, sondern Teil davon. Plane den Zwei-Konten-Test fest ein, bevor du deinen Link zum ersten Mal teilst, und wiederhole ihn nach jeder größeren Änderung an Tabellen oder Rollen. Wenn du noch zwischen Tools schwankst, hilft dir der Vergleich Lovable, Bolt oder Replit fürs Bezahl-Produkt.

Deine To-dos für diese Woche:

1. Zwei Testkonten anlegen und den Test für jede Tabelle durchspielen.
2. Den Security Advisor öffnen und jede Warnung abarbeiten.
3. Im Quelltext der Live-Seite nach „key“ und „secret“ suchen.

Den Rest der Strecke bis zum Livegang findest du in der Launch-Checkliste.

Fazit

Ein Scan gibt dir ein gutes Gefühl, ein Test mit zwei Konten gibt dir Gewissheit. Wer weiß, wie man die eigene App wie ein Fremder prüft, geht ruhiger live. Für sensible Daten oder zahlende Geschäftskunden ersetzt das keinen Blick von Fachleuten.

Du willst dein Produkt nicht nur bauen, sondern auch sauber absichern und live bringen? Trag dich in die Warteliste fürs Bootcamp ein und schildere uns vorab deine Idee.