Leitfaden
Lovable-Sicherheit: So machen Sie Ihre Lovable-App sicher
Lovable bringt eigene Sicherheitsprüfungen mit: einen Schnellscan, der bei jeder Veröffentlichung läuft, und einen tieferen Scan auf Abruf. Die Verantwortung dafür, dass Ihre App die Daten ihrer Nutzer schützt, liegt laut Lovable aber bei Ihnen. Das am häufigsten dokumentierte Problem sind Zugriffsregeln der Datenbank, die fremde Daten durchlassen. Eine Lovable-App ist deshalb erst dann sicher, wenn Sie vor dem Launch mit zwei Testkonten und ohne Anmeldung geprüft haben, dass jeder Nutzer nur seine eigenen Daten erreicht.
- Öffentlich dokumentiert ist vor allem ein Fehlerbild: Zugriffsregeln (Row Level Security), die fehlen oder zu weit sind. Dazu gibt es den Eintrag CVE-2025-48757, den Lovable bestreitet.
- Das Risiko entsteht weniger im erzeugten Code als im Ablauf: Man beschreibt, was die App tun soll, selten, was sie nicht tun darf. Fehlende Verbote fallen beim eigenen Testen nicht auf.
- Der Lovable-Scan ist ein guter erster Schritt. Lovable beschreibt die eingebauten Scanner als statische Analyse und schreibt selbst, dass sie keine gründliche Sicherheitsprüfung ersetzen.
- Vor dem Launch: Deep scan ausführen, mit zwei Konten gegenprüfen, Secrets und serverseitige Funktionen kontrollieren. Die Checkliste unten hat zwölf Punkte.
Was dokumentiert ist
CVE-Eintrag und Lovables eigene Angaben.
Zum AbschnittWarum es passiert
Die Mechanik hinter offenen Zugriffsregeln.
Zum AbschnittDer Lovable-Scan
Was er prüft und wo er endet.
Zum AbschnittCheckliste
Zwölf Punkte vor dem Launch.
Zum AbschnittExterner Check
Wann er sich lohnt.
Zum AbschnittWas über Sicherheitsprobleme in Lovable-Apps dokumentiert ist
Wer nach „Lovable Sicherheit“ sucht, stößt schnell auf zwei Arten von Quellen: einen CVE-Eintrag aus dem Jahr 2025 und Lovables eigene Dokumentation. Beide beschreiben im Kern dasselbe Fehlerbild, ziehen daraus aber unterschiedliche Schlüsse.
Der CVE-Eintrag CVE-2025-48757
Am 30.05.2025 wurde CVE-2025-48757 veröffentlicht. Der Eintrag lautet im Original:
„An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites. NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.“
Auf Deutsch: Unzureichende Row-Level-Security-Policies in Lovable bis zum 15.04.2025 erlauben nicht angemeldeten Angreifern aus der Ferne, beliebige Datenbanktabellen der erzeugten Seiten zu lesen oder zu beschreiben. Der Eintrag ist als „disputed“ markiert. Der Anbieter bestreitet ihn mit der Begründung, dass jeder einzelne Kunde der Lovable-Plattform die Verantwortung für den Schutz der Daten seiner Anwendung übernimmt.
Der Eintrag ordnet den Fehler der Klasse CWE-863 (Incorrect Authorization) zu und enthält eine CVSS-3.1-Bewertung von 9,3 (kritisch). Die NVD führt denselben Text mit den Kennzeichen „disputed“ und „exclusively-hosted-service“. Für Sie als Betreiber ist der Streit um die Zuständigkeit zweitrangig. Beide Seiten beschreiben dieselbe Lage: Fehlt eine Zugriffsregel oder ist sie zu weit, sind die Daten offen, und die Verantwortung für die Regeln Ihrer App tragen Sie.
Was Lovable selbst schreibt
Lovable geht offen mit dem Thema um. Im Blogbeitrag „Secure Vibe Coding“ vom 09.06.2025 schreibt das Unternehmen, dass mit Supabase verbundene Apps auf Row Level Security beruhen und Daten offenliegen können, wenn Policies fehlen oder zu weit gefasst sind. Lovable habe dafür den Security Advisor von Supabase eingebunden, und weiter: Der Scan finde viele Probleme, manchmal rutschten falsche Datenbank-Einstellungen aber durch.
Die aktuelle Lovable-Dokumentation zur Sicherheit (abgerufen am 28.10.2026) wird noch deutlicher:
- Falsch konfigurierte RLS-Regeln seien eine häufige Ursache für Datenlecks.
- Die Werkzeuge helfen, häufige Probleme zu finden, können aber keine vollständige Sicherheit garantieren.
- Sie sind selbst dafür verantwortlich, dass Ihre App die Sicherheitsanforderungen ihres Einsatzzwecks erfüllt, besonders bei sensiblen Daten.
- Für Apps mit sensiblen Daten oder kritischen Funktionen empfiehlt Lovable eine zusätzliche professionelle Sicherheitsprüfung.
Das ist eine faire Arbeitsteilung: Die Plattform liefert Werkzeuge und warnt vor typischen Fehlern, die Entscheidung, wer was sehen darf, bleibt beim Betreiber. Wie Row Level Security technisch funktioniert, welche Policy-Fehler es gibt und wie korrekte Policies aussehen, steht ausführlich in unserem Artikel Supabase Row Level Security richtig einsetzen. Dieser Artikel konzentriert sich auf das, was darum herum passiert.
Warum generierte Apps an Zugriffsregeln scheitern
Für diesen Abschnitt gibt es keine belastbare Statistik, die wir zitieren könnten. Die Mechanik ist aber gut zu erklären, und sie gilt für Lovable genauso wie für Bolt, Cursor, v0 oder andere Werkzeuge, die aus einer Beschreibung eine App erzeugen.
Man beschreibt, was die App tun soll, nicht was sie nicht tun darf
Ein Prompt wie „Nutzer können Rechnungen hochladen und ansehen“ ist eine Positivanforderung. Die Negativanforderung, dass Nutzer A die Rechnungen von Nutzer B nicht sehen darf, steht selten da. Das Werkzeug baut, was beschrieben ist, und das Ergebnis funktioniert. Ob es zu viel erlaubt, prüft im normalen Ablauf niemand, denn beim Testen mit dem eigenen Konto sieht man nur die eigenen Daten.
Fehlermeldungen entstehen nur, wenn Regeln zu streng sind
Eine zu enge Zugriffsregel erzeugt eine Fehlermeldung: Die Liste bleibt leer, das Speichern klappt nicht. Eine zu weite Regel erzeugt nichts, alles läuft. Wer die Fehlermeldung zurück in den Chat gibt, bekommt eine Änderung, die die App wieder zum Laufen bringt. Diese Änderung kann genau die Regel lockern, die eigentlich schützen sollte. Der Arbeitsablauf belohnt also Öffnen und bemerkt Schließen nicht.
Sicherheitsentscheidungen landen im Browser
Ein versteckter Admin-Knopf, ein Preis, der im Frontend berechnet wird, eine Prüfung, ob jemand angemeldet ist, die nur im React-Code steht: Für den Ersteller sieht das wie Schutz aus. Lovables Sicherheitsleitfaden sagt dazu klar, dass Frontend-Code im Browser läuft, dort eingesehen, verändert und umgangen werden kann und keine Sicherheitsentscheidungen treffen sollte. Wer die API direkt anspricht, sieht den Knopf nie.
Serverseitige Funktionen umgehen die Datenbankregeln
Für Zahlungen, E-Mails oder KI-Aufrufe erzeugt Lovable serverseitige Funktionen, etwa Edge Functions. Laut Lovable-Leitfaden umgeht Code, der mit der privilegierten Service-Rolle arbeitet, die Row Level Security. Diese Funktionen müssen also selbst prüfen, wer sie aufruft und ob er die Aktion ausführen darf. Und sie sind von außen aufrufbar, auch ohne den Weg über die Oberfläche der App. Eine Funktion, die nur prüft, ob jemand angemeldet ist, aber nicht, ob ihm der Datensatz gehört, öffnet den Zugriff an der Datenbank vorbei.
Die App wächst Prompt für Prompt
Jede neue Funktion bringt oft neue Tabellen, Spalten oder Buckets mit. Der Sicherheitsstand von letzter Woche sagt wenig über den Stand nach zwanzig weiteren Änderungen. Lovable nennt in seiner Checkliste vor dem Veröffentlichen ausdrücklich den Punkt, dass neue Tabellen keine fehlenden Policies haben dürfen. Wer nur einmal geprüft hat, prüft einen alten Stand.
KI-Funktionen bringen eine eigene Angriffsfläche mit
Viele Apps, die mit KI gebaut werden, enthalten selbst KI-Funktionen: einen Chat, eine Zusammenfassung, einen Assistenten. Dort können Eingaben von Nutzern oder Inhalte aus Dokumenten das Modell zu Aktionen verleiten, die der Nutzer selbst nicht ausführen dürfte. Hat die KI-Funktion mehr Rechte als der Nutzer, der sie bedient, wird Prompt-Injection zum Weg an den Zugriffsregeln vorbei. Mehr dazu in unserem Artikel zu Prompt-Injection.
Was der Lovable-Scan leistet und was nicht
Gegenüber dem Blogbeitrag von 2025 beschreibt die aktuelle Dokumentation mehrere Stufen:
| Prüfung und Zeitpunkt | Was sie abdeckt |
|---|---|
| Quick scan Automatisch bei jeder Veröffentlichung, außerdem auf Abruf | Feste Prüfungen in Sekunden: Datenbankregeln und Einstellungen (etwa Tabellen ohne RLS, Regeln, die jeden durchlassen, ausgeschalteter Schutz vor bekannten geleakten Passwörtern), Abhängigkeiten mit bekannten Schwachstellen |
| Deep scan Nur auf Abruf im Security-Bereich des Projekts, nicht automatisch (Ausnahme laut Doku: Apps, deren MCP-Integration Zugriff ohne Anmeldung erlaubt) | Liest den gesamten Anwendungscode: Zugriff auf fremde Daten, ungeschützte Endpunkte, unsichere Eingaben bis hin zu KI-Prompts, Secrets im Code, Zahlungslogik, Anmeldung und Konto-Wiederherstellung, Datenlecks in Fehlermeldungen |
| Sicherheits-Review im Chat Auf Ihre Anfrage, zum Beispiel „Review my app's security“ | KI-gestützte Einschätzung des Projekts mit Empfehlungen; verbraucht laut Doku Credits |
Das Ausführen von Quick und Deep scan ist laut Dokumentation kostenlos. Arbeitsbereiche können zusätzlich optionale Integrationen externer Sicherheitsanbieter anbinden, darunter dynamische, KI-gestützte Penetrationstests.
Die Grenzen, wie Lovable sie selbst beschreibt
- Statische Analyse. Die eingebauten Scanner lesen nach Lovables Beschreibung Code und Konfiguration und melden Muster, die riskant aussehen. Sie melden sich nicht als zwei verschiedene Nutzer an und versuchen nicht, mit einem Konto an die Daten des anderen zu kommen.
- Kein Ersatz für eine gründliche Prüfung. Die Dokumentation sagt das ausdrücklich, und die Übersicht des eingebauten Backends beschreibt die automatischen Datenbankprüfungen als „Not a full audit“.
- Der Deep scan läuft nicht von selbst. Wer nur veröffentlicht, bekommt den Quick scan. Die Prüfung des Anwendungscodes müssen Sie aktiv starten.
- Ihre Geschäftsregeln kennt der Scan nur aus dem Code. Dass in Ihrer App nur Mitglieder desselben Teams eine Rechnung sehen dürfen oder ein Nutzer seinen Tarif nicht selbst ändern darf, kann ein Scanner nur prüfen, wenn diese Regel irgendwo erkennbar ist. Fehlt sie ganz, gibt es nichts zu finden.
Lovable empfiehlt selbst eine Reihenfolge: erst die Scanner laufen lassen, gefundene Probleme beheben, dann vor einem größeren Release mit einem Penetrationstest bestätigen. Scanner und Tests mit echten Konten ergänzen sich, keines ersetzt das andere.
Auch das Trust Center, das Lovable für veröffentlichte Apps anbietet, ist laut Dokumentation eine informative Seite und keine Zertifizierung.
Checkliste vor dem Launch
Prüfen Sie nur Apps, die Ihnen gehören oder für die Sie eine ausdrückliche Erlaubnis haben. Die Punkte setzen kein Spezialwissen voraus, nur Zeit und zwei Testkonten.
| Prüfpunkt | So prüfen Sie es |
|---|---|
| 1. Deep scan ausgeführt | Im Security-Bereich des Projekts starten, jeden Befund mit „Critical“ und „Warning“ bewusst beheben oder mit Begründung zurückstellen, nicht nur ausblenden |
| 2. Fremde Daten unerreichbar | Mit Konto A Daten anlegen, als Konto B lesen, ändern und löschen versuchen. Die Schritte im Detail stehen im Supabase-RLS-Artikel |
| 3. Nichts ohne Anmeldung | Die App in einem privaten Browserfenster öffnen und Seiten, Datei-Links und API-Aufrufe ohne Anmeldung wiederholen |
| 4. Keine Secrets im Frontend | Im Browser die geladenen JavaScript-Dateien nach Schlüsseln durchsuchen, etwa nach sk_, secret oder service_role. Geheime Schlüssel gehören in die Secrets-Verwaltung und werden nur serverseitig gelesen |
| 5. Neue Tabellen abgesichert | Nach jeder größeren Änderung prüfen, ob neue Tabellen Zugriffsregeln haben. Lovable zeigt alle Policies unter More → Database → Manage → Policies |
| 6. Rechte serverseitig geprüft | Admin-Bereiche und Rollen dürfen nicht nur über ausgeblendete Knöpfe geschützt sein. Test: die Aktion als normaler Nutzer direkt aufrufen |
| 7. Kritische Felder geschützt | Felder wie Rolle, Tarif, Guthaben oder Freigabestatus darf der Nutzer nicht selbst ändern können, auch nicht über die API |
| 8. Serverfunktionen prüfen den Aufrufer | Jede Edge Function und jede Server-Route prüft, wer aufruft und ob ihm der betroffene Datensatz gehört, nicht nur, ob er angemeldet ist |
| 9. Dateien privat | Rechnungen, Ausweise und Verträge liegen in privaten Buckets. Test: Datei-URL im privaten Fenster öffnen |
| 10. Anmeldung belastbar | Passwort-Reset, E-Mail-Bestätigung und Schutz vor bekannten geleakten Passwörtern prüfen; Lovable nennt diese Einstellung ausdrücklich vor dem Launch |
| 11. Zahlungen serverseitig | Preise, Freischaltungen und bezahlte Funktionen werden auf dem Server entschieden, nicht im Browser |
| 12. KI-Funktionen begrenzt | Eine eingebaute KI-Funktion hat höchstens die Rechte des Nutzers, der sie bedient. Test: per Eingabe versuchen, fremde Daten abzufragen |
Interne Werkzeuge, die nicht öffentlich sein sollen, stellen Sie in Lovable zusätzlich auf Sichtbarkeit nur für den Arbeitsbereich und prüfen, dass sie nicht öffentlich veröffentlicht sind.
Wann ein externer Sicherheitscheck sinnvoll ist
Für einen Prototyp mit Testdaten reicht die Checkliste oben. Sobald echte Nutzer und echte Daten im Spiel sind, ändert sich die Rechnung. Ein externer Check lohnt sich vor allem, wenn eine dieser Situationen zutrifft:
- Die App verarbeitet personenbezogene oder sensible Daten, etwa Gesundheits-, Finanz- oder Vertragsdaten.
- Mehrere Kunden, Teams oder Mandanten teilen sich die App und dürfen sich gegenseitig nicht sehen.
- Es gibt Zahlungen, Guthaben oder freischaltbare Funktionen.
- Ein Launch an zahlende Kunden, ein Investorengespräch oder der Sicherheitsfragebogen eines Geschäftskunden steht an.
- Niemand im Team hat die Zugriffsregeln selbst gelesen und verstanden.
Der Unterschied zu einem Scan liegt in der Methode: Eine manuelle Prüfung arbeitet mit mehreren Testkonten gegen die laufende App und versucht gezielt, aus dem eigenen Konto auszubrechen. Jeder Befund wird mit einem nachvollziehbaren Nachweis belegt. Genau dafür haben wir den Sicherheitscheck für KI-gebaute Apps zugeschnitten. Werden bei einem Vorfall tatsächlich personenbezogene Daten abgerufen, kann das eine Meldepflicht nach Art. 33 DSGVO auslösen. Ob das im Einzelfall zutrifft, ist eine Rechtsfrage. Dieser Artikel ist keine Rechtsberatung.
Ist Ihre Lovable-App bereit für echte Nutzer?
Wir prüfen Apps aus Lovable, Bolt, Cursor, v0 und ähnlichen Werkzeugen im schriftlich vereinbarten Umfang: Zugriffsregeln mit zwei Testkonten, Schlüssel und Secrets im Frontend, Storage, Anmeldung, Edge Functions und KI-Funktionen. Jeder Befund kommt mit Nachweis und konkretem Korrekturvorschlag, nach Ihrer Korrektur folgt ein Nachtest.
App-Sicherheitscheck anfragenCyberSec42 ist eine unabhängige technische Sicherheitsprüfung, keine akkreditierte Zertifizierungsstelle und keine Rechtsberatung. CyberSec42 steht in keiner Verbindung zu Lovable oder Supabase.
Häufige Fragen
Ist Lovable sicher?
Lovable bringt eigene Sicherheitsprüfungen mit und warnt vor typischen Fehlern. Ob eine einzelne App sicher ist, hängt aber an ihren Zugriffsregeln, serverseitigen Funktionen und dem Umgang mit Secrets. Dafür ist laut Lovable der Betreiber der App verantwortlich.
Was ist CVE-2025-48757?
Ein im Mai 2025 veröffentlichter CVE-Eintrag zu unzureichenden Row-Level-Security-Policies in mit Lovable erzeugten Apps bis zum 15.04.2025, über die nicht angemeldete Angreifer Tabellen lesen oder beschreiben konnten. Lovable bestreitet den Eintrag, er ist als „disputed“ markiert.
Reicht der Lovable Security Scan vor dem Launch?
Er ist ein guter und kostenloser erster Schritt, besonders der Deep scan, den Sie selbst starten müssen. Lovable beschreibt die eingebauten Scanner als statische Analyse und schreibt, dass sie keine gründliche Sicherheitsprüfung ersetzen. Ergänzen Sie ihn mindestens um einen Test mit zwei Konten.
Wo speichere ich API-Schlüssel in einer Lovable-App?
In der Secrets-Verwaltung von Lovable, gelesen nur in serverseitigem Code wie Edge Functions. Schlüssel im Frontend-Code sind für jeden Besucher sichtbar und gelten laut Lovable als kompromittiert. Der öffentliche Supabase-Schlüssel ist die Ausnahme, er ist für das Frontend gedacht.
Wann brauche ich eine externe Sicherheitsprüfung?
Wenn die App echte personenbezogene Daten, Zahlungen oder mehrere Kunden verwaltet oder ein Launch, Investorengespräch oder Kundenaudit ansteht. Lovable selbst empfiehlt für Apps mit sensiblen Daten eine zusätzliche professionelle Prüfung.
Weiterlesen
- Vibe Coding Sicherheit: die Checkliste
- Supabase Row Level Security richtig einsetzen
- API-Pentest-Checkliste
- Pentest-Anbieter auswählen
- Leistung: Sicherheitscheck für KI-gebaute Apps