Ist eure Lovable-App sicher? Die 5 häufigsten Sicherheitslücken

1. Datenbank ohne Zugriffsschutz (Row Level Security). Mit Abstand der häufigste kritische Fehler. Lovable-Apps sprechen ihre Supabase-Datenbank direkt aus dem Browser an. Ohne Row Level Security kann jeder Besucher mit dem öffentlichen Schlüssel alle Datensätze lesen oder ändern, nicht nur die eigenen. Genau das steckt hinter CVE-2025-48757.

2. Der Vollzugriffs-Schlüssel im Browser (service_role). Supabase hat einen öffentlichen Schlüssel für den Browser und einen geheimen mit vollem Zugriff. Landet der geheime im ausgelieferten Code, ist jeder Schutz wertlos: Wer ihn liest, kann die ganze Datenbank lesen, ändern und löschen. Was ihn ausmacht, steht im Glossar zum service_role-Key.

3. Rollen werden nur im Frontend geprüft. Die App blendet den Admin-Bereich aus, wenn ihr kein Admin seid, aber die Datenbank fragt nicht nach. Wer die Anfrage aus dem Browser selbst abschickt, bekommt die Daten trotzdem. Die Rolle muss in der Datenbank oder auf dem Server geprüft werden.

4. Schlüssel und .env-Dateien öffentlich. Schlüssel für Bezahldienste, KI-Dienste oder Mailversand gehören auf den Server, nicht in den Browser. Eine versehentlich veröffentlichte .env-Datei lässt sich oft einfach über die URL aufrufen. Beides bedeutet fremde Kosten auf eurer Rechnung oder Missbrauch in eurem Namen.

5. Fehlende Anmeldeprüfung an sensiblen Stellen. Eine Edge Function oder Schnittstelle ist „geschützt“, prüft aber gar nicht, ob der Aufrufer angemeldet und berechtigt ist. Im Februar 2026 fand ein Sicherheitsforscher in einer Lovable-App sogar eine Prüfung mit umgedrehter Logik: Angemeldete wurden abgewiesen, Anonyme durchgelassen.

Supabase gibt jedem Projekt zwei Arten von Schlüsseln. Der öffentliche heißt in älteren Projekten anon-Key, in neuen publishable key (beginnt mit sb_publishable_). Er darf im Browser stehen und sieht nur, was eure Row-Level-Security-Regeln erlauben. Der geheime heißt service_role-Key, in neuen Projekten secret key (beginnt mit sb_secret_). Er umgeht jede RLS-Regel und darf jede Zeile jeder Tabelle lesen, ändern und löschen.

Wo ihr ihn findet: im Supabase-Dashboard eures Projekts unter Settings → API Keys. Dort stehen die neuen publishable und secret keys; die alten JWT-Schlüssel anon und service_role liegen im selben Bereich bei den Legacy-Schlüsseln. Den geheimen Schlüssel müsst ihr erst einblenden. Kopiert ihn nur in serverseitige Umgebungsvariablen, nie in eine Variable mit dem Präfix NEXT_PUBLIC_ oder VITE_: Beide werden fest ins Browser-Bundle kompiliert.

Was sich 2026 ändert: Supabase will anon und service_role laut eigener Doku bis Ende 2026 abschalten, ein genaues Datum steht noch aus. Neue Schlüssel anzulegen deaktiviert die alten nicht, das ist ein eigener Schritt. Und neue secret keys lehnt Supabase im Browser mit 401 ab. Das ist ein Schutznetz, kein Freibrief: Außerhalb des Browsers, etwa in einem Skript, funktioniert ein geleakter Schlüssel weiter.

Wenn der Schlüssel öffentlich war: sofort einen neuen erzeugen, den alten löschen bzw. deaktivieren, die Server-Variablen umstellen und prüfen, was in der Zwischenzeit verändert wurde. Ob ein service_role-Schlüssel in eurem ausgelieferten Code steht, prüft der Scan mit der Regel service_role-Schlüssel im Browser.

Wer nach „Lovable data breach“ sucht, findet drei Fälle, die man auseinanderhalten sollte. Mai 2025, CVE-2025-48757: Der Forscher Matt Palmer hatte 1.645 öffentlich präsentierte Lovable-Projekte gescannt und bei 170 unzureichende Row-Level-Security-Regeln gefunden, 303 Endpunkte waren betroffen. Die CVE wurde im Mai 2025 veröffentlicht. Lovable bestreitet sie, weil jeder Kunde für den Schutz der Daten seiner App verantwortlich sei.

Februar 2026, eine einzelne App: Laut The Register fand ein Sicherheitsforscher in einer auf Lovables Discover-Seite präsentierten App 16 Schwachstellen, sechs davon kritisch, darunter eine Anmeldeprüfung mit umgedrehter Logik. Nach seinen Angaben waren 18.697 Nutzerdatensätze abrufbar, darunter Konten von Studierenden. Lovable widersprach in Teilen: Das Projekt enthalte Code, den Lovable nicht erzeugt habe, die Datenbank sei nicht bei Lovable gehostet gewesen, und die Empfehlungen des Sicherheits-Scans umzusetzen sei Sache der Nutzer.

April 2026, die Plattform selbst: Am 20. April 2026 machte ein Sicherheitsforscher öffentlich, dass angemeldete Lovable-Nutzer Chatverläufe und Quellcode öffentlicher Projekte anderer einsehen konnten. Lovable bestritt zunächst ein Datenleck; in der Stellungnahme vom 22. April nennt das Unternehmen eine Backend-Änderung vom Februar als Ursache, betroffen war demnach der Zeitraum vom 3. Februar bis 20. April 2026, behoben binnen zwei Stunden. Private Projekte und Lovable Cloud waren laut Lovable nicht betroffen. Wer in Prompts Schlüssel oder echte Kundendaten verwendet hat, sollte prüfen, ob das Projekt in diesem Zeitraum öffentlich war, und Schlüssel im Zweifel neu erzeugen. Was das datenschutzrechtlich für euch bedeutet, steht in Ist Lovable DSGVO-konform?

Das Muster: Zwei von drei Fällen lagen in der gebauten App, nicht in Lovable. Genau deshalb reicht die Frage „Ist Lovable sicher?“ nicht. Die bessere Frage ist: Ist eure App sicher?

In Deutschland, Österreich und der Schweiz ist eine offene Datenbank nicht nur ein technisches, sondern ein rechtliches Problem. Werden personenbezogene Daten ohne angemessenen Schutz verarbeitet (Art. 32 DSGVO) und gelangen sie an Unbefugte, ist das in aller Regel ein meldepflichtiger Vorfall nach Art. 33 DSGVO, mit 72 Stunden Frist.

Dazu kommen die kleineren, aber häufigen Themen: Google Fonts, die zur Laufzeit von Google-Servern nachgeladen werden, Tracker, die vor der Einwilligung feuern, und fehlende Pflichtangaben im Impressum. Der decivo Scan prüft diese Datenschutz-Signale als eigenen Bereich mit.

Ehrlich gesagt: Ein Scan ist eine technische Einordnung, keine Rechtsberatung im Einzelfall. Für euren konkreten Fall gehört ein Blick von Datenschutzbeauftragten oder Anwält:innen dazu. Was Lovable beim AVV und Serverstandort zusagt und welche Pflichten eure App selbst hat, steht in Ist Lovable DSGVO-konform?