Lovable-Datenleck: So prüfst du korrigierte Zugriffsrechte

Zurück

Kevin Riedl

15 Min. Lesezeit · 4. November 2026
Zuletzt geprüft 4. November 2026

Weiter

Du hast nach einer Sicherheitswarnung eine Datenbank-Policy geändert. Dein eigenes Konto funktioniert weiterhin. Bevor du den Befund schließt, prüfe, ob ein anderer Kunde deine privaten Datensätze lesen kann und ob eine Anfrage ohne Anmeldung Daten erhält, die ihr nicht zustehen.

Um korrigierte Zugriffsrechte deiner Lovable-App zu prüfen, legst du die beabsichtigten Berechtigungen fest und testest erlaubte sowie verbotene Operationen mit synthetischen Datensätzen. Anschließend wiederholst du diese Tests über die bereitgestellten Datenzugriffe mit echten Anwendungsidentitäten. Bewahre die Ergebnisse vor und nach der Änderung auf. Ein bestandener lokaler Policy-Test belegt das Verhalten einer bestimmten Regel; der Zugriff in Produktion braucht eine eigene Nachprüfung.

Recherchestand: 4. November 2026. Die folgenden Zahlen zum Vorfall stammen von den genannten Forschern. Unser separates Beispiel verwendet synthetische Daten und lokale PostgreSQL-Policies. Die Prüfungen an der gehosteten Anwendung sind ein vorgeschlagenes Vorgehen für eine Umgebung, die dir gehört oder die du prüfen darfst.

Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]

Was zeigt der Bericht zum Lovable-Datenleck?

Der Novemberbericht von Crissy Field beschreibt Datenabrufe ohne Anmeldung in ausgewählten, mit Lovable erstellten Anwendungen. Die Forscher identifizierten Projekte in Common-Crawl-Archivdaten von Dezember 2025 bis September 2026. Die Zahlen aktualisieren den Handelsblatt-Beitrag vom 2. November und beziehen sich auf unterschiedliche Teilmengen.

Die genannten 30 % entsprechen 7.403 von 24.664 Websites und sind keine bestätigte Datenleckquote. E-Mail-Treffer können öffentliche Kontakte oder Testdaten sein; die Stichprobe ist nicht repräsentativ. Lovables eigenes Datenbankangebot war ausgeschlossen.

Die Beispiele umfassen über 200.000 Nachrichten eines deutschen Lifestyle-Forums, mehr als 1.000 Datensätze mit Identitätsangaben einschließlich Passnummern bei einem Dienstleister sowie Zahlungsinformationen in Verkaufsdatensätzen. Der Bericht nennt keine konkreten Zahlungskartenfelder und weist keinen Missbrauch nach. Daraus lässt sich weder die Betroffenheit deiner Anwendung noch ihr aktueller Reparaturstand ableiten.

Ist das derselbe Vorfall wie Lovables offengelegte Chatverläufe?

Der Vorfall mit Lovables Chatverläufen im April betraf den Zugriff auf das Projekt im Entwicklungswerkzeug. Die Datenbank der bereitgestellten Anwendung ist eine andere Zugriffsebene. In der Stellungnahme vom 22. April beschreibt Lovable eine Regression vom 3. Februar bis zum 20. April: Angemeldete Lovable-Nutzer konnten mit dem Link zu einem öffentlichen Projekt dessen Quellcode und Chatverlauf abrufen.

Lovable erklärt, die Regression behoben zu haben; private Projekte und Lovable Cloud seien davon nicht betroffen gewesen. Diese Aussage überprüft nicht die Berechtigungen deiner bereitgestellten Anwendung.

Unser Leitfaden zur Due Diligence von Lovable-Anwendungen behandelt die weitergehende Prüfung von Eigentum und Einsatzreife. Diese Nachprüfung beantwortet die engere Frage, ob ein konkreter Befund zum Datenzugriff geschlossen werden kann.

Warum können Daten trotz Login-Seite abrufbar sein?

Eine Login-Seite steuert die Benutzeroberfläche. Welche Daten eine Anfrage erreichen darf, muss das Backend durchsetzen. Bei einer Supabase-App mit direkter Browseranbindung beweisen weder eine versteckte Seite noch eine in JavaScript gefilterte Liste, dass die Datenbank den Zugriff korrekt beschränkt. Prüfe die Datenanfrage selbst, auch ohne angemeldeten Nutzer.

Die Dokumentation zu Supabase-API-Schlüsseln unterscheidet den Publishable Key von der Identität eines Nutzers. Ein Publishable Key gehört in öffentliche Clients. Ohne Nutzersitzung verwenden Anfragen anon, mit einer angemeldeten Sitzung authenticated. Secret Keys und ältere service_role-Zugangsdaten brauchen eine gesonderte Behandlung, weil ihr erhöhter Zugriff RLS umgeht.

Row-Level Security ist der PostgreSQL-Mechanismus, der festlegt, auf welche Zeilen eine Operation zugreifen darf. Der RLS-Leitfaden von Supabase trennt Tabellenrechte von Zeilen-Policies: Grants erlauben eine Operation auf der Tabelle; Policies begrenzen die betroffenen Zeilen. Prüfe beides. Ein entfernter Button im Frontend ändert keine dieser Berechtigungen.

Eine Listenabfrage mit der ID des aktuellen Nutzers kann beispielsweise genau die richtigen Zeilen anzeigen, während eine umfassendere erlaubte Abfrage weitere Datensätze liefert. Für die Nachprüfung ändern wir den angeforderten Datensatz und lassen den Aufrufer unverändert. Das Backend muss die Besitzerregel auch dann durchsetzen, wenn die Oberfläche eine solche Anfrage nie anbieten würde.

Was muss ein Berechtigungstest nachweisen?

Ein Berechtigungstest muss zeigen, dass erlaubte Arbeit gelingt und unzulässige Zugriffe unter einer bekannten Identität scheitern. Beginne mit zwei synthetischen Nutzern und getrennten privaten Datensätzen. Lege zuerst die erlaubten Felder und Operationen fest. Ein Test kann eine Policy korrekt bestätigen, obwohl diese dem beabsichtigten Produktverhalten widerspricht.

Nimm beabsichtigt öffentliche Inhalte als eigenen positiven Testfall auf. Ein öffentlicher Katalog soll weiterhin lesbar sein, wenn das seine Aufgabe ist. Bei privaten Daten muss der Besitzer den vorbereiteten Datensatz unmittelbar vor dem Test des fremden Zugriffs lesen können. Eine leere Tabelle oder eine defekte Umgebung kann sonst jede Prüfung auf verweigerten Zugriff erfolgreich aussehen lassen.

Unterscheide außerdem Gastkonten ausdrücklich. Anonyme Anmeldungen bei Supabase Auth erzeugen Auth-Nutzer mit der Rolle authenticated und dem JWT-Claim is_anonymous. Wenn du ausschließlich dauerhafte Konten zulassen willst, reicht diese Rolle dafür nicht aus. Ergänze die passende Policy-Bedingung und die entsprechende Testidentität.

Bei Teams und Organisationen ersetzt du die einfache Besitzerregel durch die tatsächlichen Mitgliedschafts- und Rollenregeln. Prüfe auch einen Nutzer, dessen Mitgliedschaft entfernt wurde. Entscheide, welche Hintergrundaufgaben danach weiterhin berechtigt sind, und teste genau diese Vorgabe. Nicht jeder Zugriff muss auf dieselbe Weise enden.

Was ergab unser synthetischer PostgreSQL-Test?

Unser synthetischer PostgreSQL-Test reproduzierte offene Lesezugriffe, zwei unvollständige Korrekturen und eine auf Besitzer und Mandant begrenzte Policy. Alle 23 protokollierten Prüfungen bestanden mit dem jeweils erwarteten Ergebnis. Dazu gehörte der Nachweis der absichtlich unsicheren Zustände. Im korrigierten Zustand funktionierten die erlaubten Operationen, während die getesteten Zugriffe auf fremde Nutzer und Mandanten abgewiesen wurden.

Wir verwendeten Node.js 24.22.1 und @electric-sql/pglite 0.5.15; die Laufzeit meldete PostgreSQL 18.6. PGlite stellt eine PostgreSQL-Laufzeit im Arbeitsspeicher bereit. Das Testprojekt legt drei Notizen an: Alice und Bob teilen sich Mandant A, Carol gehört zu Mandant B. Jeder Nutzer besitzt eine Notiz.

Der Testtreiber prüft vor jeder Operation die tatsächlich wirksame PostgreSQL-Rolle sowie Nutzer- und Mandanten-ID. Bob und Carol lesen jeweils genau ihre eigene vorbereitete Notiz. Alices Identität mit einer falschen Mandanten-ID liest null Zeilen. Diese positiven Kontrollen unterscheiden eine funktionierende Beschränkung von einer leeren oder unerreichbaren Datenbank.

Dies ist der unveränderte Policy-Ausschnitt aus dem Testprojekt. Die Hilfsfunktionen fixture.uid() und fixture.tenant_id() lesen SQL-Einstellungen, die der Test vorgibt. Diese Funktionen ersetzen die Identität lokal und sind weder Supabase-Auth-Funktionen noch eine JWT-Prüfung. Der Ausschnitt ist keine Migration für Produktion; eine vertrauenswürdige Prüfung der Mandantenzugehörigkeit wurde damit nicht getestet.

DROP POLICY signed_in_read ON public.notes;
CREATE POLICY private_notes ON public.notes FOR ALL TO authenticated
  USING (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id())
  WITH CHECK (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id());

Alices erlaubte Update-, Insert- und Delete-Operationen lieferten jeweils einen erwarteten Datensatz zurück. Ein Update von Bobs oder Carols Notiz sowie das Löschen von Bobs Notiz lieferten null Zeilen. Versuche, den Besitzer oder Mandanten zu ändern oder eine Notiz für Bob anzulegen, lösten SQLSTATE 42501 aus. Nach jeder abgewiesenen Schreiboperation verglich der Testtreiber einen Snapshot der gesamten Tabelle und bestätigte, dass sie unverändert war.

Eine separate Rolle mit BYPASSRLS las trotz Alices Testidentität alle drei Datensätze. Außerdem deaktivierten wir RLS gezielt erneut: Die Prüfung des Besitzerzugriffs erkannte die zusätzlichen Zeilen. Nach erneuter Aktivierung kam wieder genau eine Zeile zurück. Der Regressionstest reagiert damit auf eine tatsächliche Policy-Änderung.

Policy-Regressionstest und protokollierte Ergebnisse herunterladen. Entpacke das Archiv und führe anschließend aus:

npm ci --ignore-scripts
npm test

Das Paket enthält die Lockdatei für die Abhängigkeiten und results.json. Es prüft PostgreSQL-Grants und -Policies mit kontrollierten lokalen Identitäten. Supabase Auth, JWT-Prüfung, PostgREST, gehostete HTTP-Antworten, Views, Storage und Edge Functions werden nicht getestet. Die folgenden Prüfungen an der bereitgestellten Anwendung bleiben für deren tatsächlichen Umfang erforderlich.

Warum kann eine Korrektur trotz aktiviertem RLS scheitern?

Auch eine Tabelle mit aktiviertem RLS kann Zugriffe erlauben, die der beabsichtigten Regel widersprechen. Prüfe alle anwendbaren Policies und Privilegien, anschließend alternative Datenzugriffe und die zurückgegebenen Felder. Erlaubte Operationen müssen weiterhin funktionieren; zugleich musst du begrenzen, welche neuen Werte eine Schreiboperation speichern darf.

Die PostgreSQL-Referenz zu Zeilen-Policies erklärt, dass permissive Policies mit OR verknüpft werden. Eine neue, enge Besitzer-Policy beschränkt das Ergebnis nicht, solange eine anwendbare Allow-all-Policy bestehen bleibt. Die Referenz erklärt auch, warum Superuser, Rollen mit BYPASSRLS und normalerweise Tabellenbesitzer ungeeignet sind, um gewöhnliche Aufrufer im Test zu vertreten.

Für Zeilen und Felder brauchst du getrennte Entscheidungen. Laut Supabase-Leitfaden zu Spaltenrechten legt RLS nicht fest, welche Spalten innerhalb einer erlaubten Zeile zugänglich sind. Wir würden öffentliche Profilfelder von internen Datensätzen trennen oder bewusst entworfene Spaltenrechte einsetzen. Prüfe, ob Tabellenrechte weiterhin den Zugriff auf Spalten erlauben, die du sperren willst.

Beim Aufruf einer Funktion können sich die wirksamen Privilegien ändern. Supabase dokumentiert, dass eine Datenbankfunktion mit security definer mit den Rechten ihres Besitzers läuft. Eine Beschränkung der Ausführungsberechtigung begrenzt nicht automatisch, wessen Zeilen die Funktion zurückgibt. Prüfe den Funktionscode und teste das Ergebnis aus Sicht des Aufrufers.

Erweitere eine Policy nicht bloß, damit eine fehlerhafte Ansicht wieder funktioniert. Kläre zuerst, ob ein fehlendes Grant, eine Besitzerbedingung, eine falsche Identität oder das falsche Deployment den Fehler verursacht. Wenn du die Ursache korrigierst, kann der erlaubte Ablauf funktionieren, ohne den ursprünglichen Zugriffsweg wieder zu öffnen.

Wie prüfst du die bereitgestellte Anwendung erneut?

Teste die bereitgestellte Anwendung über jeden Datenzugriff, der zum Befund gehört, mit echten Anwendungsidentitäten und synthetischen Datensätzen. Halte die Antwort und jede dauerhafte Änderung fest. So prüfst du zugleich die Sitzungsverarbeitung, Konfiguration und den Code, der die Nutzer aktuell bedient.

Die Testübersicht von Supabase unterscheidet Datenbanktests von Anwendungstests über den tatsächlich eingesetzten Client. Übertrage dieselben erlaubten und verbotenen Fälle auf beide Ebenen. Eine Migration in Git dokumentiert die beabsichtigte Änderung. Prüfe zusätzlich, ob die Zielumgebung sie angewendet hat.

1. Bestimme das Ziel. Erfasse Projekt, Deployment-Revision, Migration und freigegebene Routen. Nutze getrennte Browserprofile oder Clients für A, B und Anfragen ohne Anmeldung. Eine gespeicherte Sitzung darf den Aufrufer nicht unbemerkt ändern.
2. Lege kontrollierte Datensätze an. Gib A und B eindeutig unterschiedliche synthetische Werte. Behalte einen erlaubten Lesezugriff bei, der die Existenz des Zieldatensatzes und die funktionierende Route bestätigt. Sammle keine unbeteiligten Kundendaten als Nachweis.
3. Prüfe Lesen und Schreiben. Teste Listen, direkte Datensatzanfragen sowie die tatsächlich vorgesehenen Create-, Update- und Delete-Aktionen. Prüfe die zurückgegebenen Felder. Bestätige nach einer abgewiesenen Schreiboperation, dass die ursprüngliche Zeile unverändert ist.
4. Bewahre das Ergebnis auf. Sichere bereinigte Anfragen und Antworten, die wirksame Identität, Zeilenzahlen und den Zustand vor und nach der Operation. Protokolliere fehlende oder abgelaufene Sitzungen getrennt vom Fall eines gültig angemeldeten, aber falschen Nutzers.

Nimm die Zugriffswege auf, die deine Anwendung bereitstellt, und kennzeichne ungeprüfte Wege als offen. Unser Leitfaden zum Audit von Vibe-Coded Software erklärt, wie daraus ein vereinbarter Prüfauftrag mit konkreten Ergebnissen wird.

Was prüft Lovables Sicherheitsscan?

Lovables Quick- und Deep-Sicherheitsscans untersuchen Code und Konfiguration in unterschiedlichem Umfang. Nutze die Befunde zusammen mit deiner Berechtigungsmatrix. Ein Scan kann weder jede Geschäftsregel festlegen noch belegen, dass dein A/B-Test an der bereitgestellten Anwendung ausgeführt wurde.

Laut aktueller Sicherheitsübersicht prüft Quick beim Veröffentlichen Datenzugriffseinstellungen, bekannte Schwachstellen in Abhängigkeiten und MCP-Zugriffe ohne Authentifizierung. Deep ergänzt die Analyse des Anwendungscodes und enthält Quick. Die eingebauten Scans analysieren Code und Konfiguration; optionale Penetrationstests zur Laufzeit sind davon getrennt. Deep kann auf Abruf, über Enterprise-Zeitpläne oder beim Veröffentlichen einer App mit unauthentifiziertem MCP-Zugriff starten.

Die Security-Ansicht des Projekts ordnet Befunde einer Codeversion zu. Wiederhole veraltete Scans und prüfe ignorierte Befunde, die in der Zahl offener Probleme fehlen. „No issues found“ bedeutet, dass der jüngste Scan nichts gefunden hat. Die Dokumentation sagt ausdrücklich, dass Scanner nicht jedes Risiko erkennen. Ob kritische Befunde die Veröffentlichung blockieren, hängt von den Workspace-Einstellungen ab.

Bewahre den Scan-Zeitpunkt und die geprüften Befunde zusammen mit den Ergebnissen der Nachprüfung auf. Kontrolliere automatisch geänderte Policies und führe den Regressionstest erneut aus. Für Änderungen von Menschen und Assistenten gelten dieselben Abnahmekriterien.

Was tun, wenn vertrauliche Daten bereits abrufbar waren?

Wenn deine eigene Anwendung vertrauliche Daten an einen unberechtigten Aufrufer liefert, beschränke den betroffenen Zugriffsweg und beziehe die Verantwortlichen für Sicherheit und Datenschutz ein. Wir empfehlen, unmittelbare Eindämmung und Untersuchung zu trennen: Eine Zugriffsbeschränkung kann weitere Abrufe stoppen. Ob zuvor Daten abgerufen wurden, lässt sich aus einer bestandenen Nachprüfung allein nicht feststellen.

Sichere relevante Konfigurationen, den Deployment-Verlauf und vorhandene Logs, bevor Änderungen nützliche Spuren beseitigen. Dokumentiere, welche Datensätze und Operationen zum Befund gehören. Bewahre sensible Nachweise an einem kontrollierten Ort auf. Im Issue-Tracker sollten normalerweise synthetische Reproduktionen oder bereinigte Unterlagen liegen.

Stimme die Eindämmung mit dem Systemverantwortlichen ab: Beschränke eine exponierte Funktion, entferne ein unbeabsichtigtes Grant, pausiere die betroffene Funktionalität oder korrigiere ihre Policy. Wurde eine privilegierte Zugangsinformation offengelegt, mache sie nach dem Rotationsverfahren des Anbieters ungültig und beseitige zugleich die Offenlegung. Behandle einen öffentlichen Publishable Key entsprechend seiner vorgesehenen Rolle.

Eine leere Antwort nach dem Fix beweist nicht, dass die Daten vorher geschützt waren. Halte getrennt fest, wann der Fehler beobachtet wurde, wann die Eindämmung wirksam war und wann die Nachprüfung der bereitgestellten Anwendung bestand. Das verantwortliche Incident-Team kann Meldepflichten und weitere Verpflichtungen dann anhand der tatsächlichen Umstände beurteilen.

Wann kannst du den Berechtigungsbefund schließen?

Schließe einen Berechtigungsbefund, wenn die vereinbarten Tests für erlaubte und verbotene Zugriffe an der bereitgestellten Anwendung bestehen, erlaubte Abläufe weiterhin funktionieren und die Nachweise die getestete Änderung sowie die Aufrufer benennen. Wir würden den Befund offen lassen, solange nur aktiviertes RLS, eine erfolgreiche Administratorabfrage oder ein grüner Scan ohne Nachprüfung auf Anwendungsebene vorliegt.

Die Cedars-Fallstudie zur technischen Bewertung beschreibt unsere Arbeit an Dokumentation, QA und einer abgegrenzten technischen Prüfung. Vereinbare die benötigten Nachweise vor Arbeitsbeginn. Über unseren Penetrationstest-Service kannst du eine autorisierte Prüfung und Nachprüfung deiner laufenden Anwendung mit uns planen.

Nutze die QA-Checkliste vor dem Software-Launch für die umfassendere Freigabeentscheidung. Für diesen Befund muss die erlaubte Anfrage gelingen und die verbotene Anfrage an derselben bereitgestellten Revision scheitern. Bewahre beide Ergebnisse auf, bevor du ihn schließt.