Ist Lovable sicher? Was 18.554 echte Lovable-Apps zeigten

Du hast etwas auf Lovable gebaut, es funktioniert, und du willst echte Menschen darauf loslassen. Irgendwann in dieser Woche hast du "ist lovable sicher" in ein Suchfeld getippt, und zurück kam entweder eine Seite über eine Sicherheitsveröffentlichung von 2025 oder ein Anbieter, der dir einen Scan verkaufen will. Keine von beiden sagte etwas über die App, die du gleich veröffentlichst.

Und hier liegt der Fehler in den meisten dieser Antworten: "ist Lovable sicher" sind drei Fragen in einem Satz, und die eine, die darüber entscheidet, ob Fremde die Daten deiner Nutzer lesen können, misst fast niemand.

Wir können sie messen. Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Checks, die jeder auf unserer Startseite kostenlos ausführen kann, über 30.998 laufende Apps laufen lassen, und 18.554 davon waren auf Lovable veröffentlicht. Das ist unsere größte Kohorte, drei von fünf Apps, die wir je gescannt haben. Das kam für sie zurück, und hier endet unser Blick.

Ist Lovable sicher?

Als Plattform ja, und mit größerem Abstand als erwartet. Was Lovable selbst ausliefert, war das sauberste der fünf Builder, die wir gemessen haben. Alles, was über eine Note entschied, saß in der App, die ihr Inhaber gebaut hat.

Stell dir einen Laden vor, dessen Lager auf der anderen Straßenseite liegt. Lovable baut den Laden: die Schaufenster, den Tresen, das Schild. Supabase gehört das Lager, und das hat sein eigenes Schloss an seiner eigenen Tür. Was der Laden einem Passanten aushändigt, ist die eine Frage. Was das Lager jedem aushändigt, der hingeht und fragt, ist eine völlig andere, und kein noch so aufgeräumter Laden ändert daran etwas.

1. Die Plattform. Veröffentlicht Lovable deine App ordentlich: gültiges Zertifikat, Domain, die nicht abläuft, nichts, was aus dem Build sickert. Das ist der Laden.
2. Der Agent. Taugt der Code, den Lovables KI schreibt. Kein Scan von außen sieht die Verkabelung, und dieser Beitrag sagt das lieber, als zu raten.
3. Die App, die du veröffentlicht hast. Was ein Fremder vom Bürgersteig aus erreicht: ein Schlüssel im Code, den ein Browser herunterlädt, ein Storage-Bucket, der seine Dateien auflistet, eine Datenbanktabelle, die jedem antwortet, der fragt.

Unsere Checks lesen die dritte Frage und zwei Teile der ersten. Zur Plattform: Das Zertifikat war auf allen 18.486 Apps gültig, bei denen wir eines lesen konnten, und keine einzige Domain von 18.554 lief bald ab. Zum Agenten haben wir nichts zu messen. Zur App haben wir 18.554 Antworten.

Was wir in 18.554 Lovable-Apps gefunden haben

Neun Checks, von außen, ohne Anmeldung und ohne Zugriff auf irgendein Konto. Wir haben nie eine Zeile gelesen: Wo eine Datenbank antwortete, haben wir gefragt, wie viele Zeilen sie herausgeben würde, und dort aufgehört. Keine App wird hier oder anderswo von uns genannt. Jeder Anteil unten bezieht sich auf die Apps, bei denen der Check geantwortet hat, denn ein Check, der nicht durchlief, ist unbekannt und nicht bestanden. Deshalb bewegen sich die Nenner. Methode und Daten stehen im Bericht.

Die Noten: 15.963 A, 370 B, 1.814 C, 402 D und 5 F. Neun Apps hatten überhaupt keinen Fund.

Diese erste Zeile ist der Grund, warum "99 % der Lovable-Apps haben ein Sicherheitsproblem" ein Satz ist, den du irgendwo lesen und ignorieren solltest. Browser-Sicherheitsheader schickt das, was deine Seite ausliefert, und auf deineapp.lovable.app ist das Lovable, weshalb jede App auf diesem Host dieselbe Antwort bekommt. Sie sind es wert, und sie sind nicht das, woraus ein D gemacht ist.

Lässt man diese Zeile weg, hatten 15.453 der 18.554 Apps sonst gar nichts. Die verbleibenden 3.092 sind der Rest dieses Beitrags.

Was Lovable richtig macht, und das ist das meiste

Drei der Zahlen oben sind die besten, die wir bei irgendeinem Builder notiert haben, und alle drei entscheidet die Plattform und nicht du.

Source Maps. 225 von 18.553 Lovable-Apps veröffentlichen die Originaldateien hinter der App, Kommentare inklusive. Das ist etwa 1 von 80. Bei Base44 schlägt derselbe Check bei 59 % der Apps an, bei Replit bei 6 %. Lovables Produktions- Build macht es standardmäßig richtig, also ist das hier meist nicht dein Problem.

Cross-Origin-Header. Null Apps von 18.518 sagten irgendeiner Website der Welt, sie dürfe ihre API aufrufen, und null erlaubten das mit den Anmelde-Cookies des Besuchers. Das ist der Fund, der am ehesten eine fremde Seite als deinen Nutzer handeln lässt, und auf Lovable tauchte er kein einziges Mal auf.

Verirrte private Dateien. Null Apps von 18.442 lieferten eine .env oder eine .git/config unter einer schlichten URL aus. Eine Lovable-App hat keinen eigenen Server, den man falsch konfigurieren könnte, also liegt hinten auch keine Datei herum.

Das ist kein Trostpflaster. Das ist der Teil der Arbeit, über den du nicht nachdenken musstest und über den bei den meisten anderen Buildern jemand nachdenkt.

Die eine Zahl, auf die es ankommt: 2.017 von 3.553

Von den Lovable-Apps, deren Supabase-Datenbank wir tatsächlich fragen konnten, gaben 57 % Zeilen an eine Anfrage ganz ohne Anmeldung heraus.

Die Nenner sind es wert, durchgegangen zu werden, denn das ist die Zahl, die alle zitieren und fast niemand einordnet. Von 18.554 Lovable-Apps nannten 6.532 ein Supabase-Projekt im ausgelieferten Code. Davon beantworteten 3.553 unsere Anfrage gut genug, dass wir urteilen konnten, die übrigen 2.979 nicht, also sind sie unbekannt und nicht sauber. Von den 3.553 gaben 2.017 Zeilen an einen Fremden heraus.

In 373 dieser Apps hieß die antwortende Tabelle nach Menschen: users, profiles, orders, messages. Das sind 373 Apps, nicht 373 Tabellen. In den anderen 1.644 war es etwas, das wir von außen nicht benennen konnten, vielleicht ein Produktkatalog, der immer öffentlich sein sollte, vielleicht etwas ganz anderes.

Gemessen an allen gescannten Lovable-Apps statt an der Teilmenge, über die wir urteilen konnten, sind 2.017 von 18.554 rund 11 von je 100. Merk dir die Zahl für zwei Abschnitte.

Warum es an der Datenbank hängt und nicht an Lovable

Wegen einer Design-Entscheidung, die richtig und bewusst getroffen ist und der Person, die sie betrifft, fast nie erklärt wird.

Eine Lovable-App hat keinen eigenen Server. Die Seite im Browser des Besuchers spricht direkt mit Supabase, weshalb sich das Ganze an einem Nachmittag bauen lässt und weshalb so wenige dieser Apps eine offene API-Route haben: Es gibt keine API von dir, die offen stehen könnte. Damit das funktioniert, müssen die Adresse deiner Datenbank und ein Schlüssel dazu in der App stehen, wo jeder sie lesen kann. Dieser Schlüssel ist der veröffentlichbare Schlüssel, und dass er öffentlich ist, ist richtig. Er gehört genau dorthin.

Damit steht zwischen einem Fremden und deiner users-Tabelle nur eine Supabase-Einstellung pro Tabelle namens Row Level Security. Ist sie an und eine Policy geschrieben, liest der öffentliche Schlüssel nur die Zeilen, die die Policy erlaubt. Ist sie aus, liest er die Tabelle.

Jetzt der Teil, der die meisten Lovable-Projekte entscheidet. Supabase schaltet Row Level Security standardmäßig für Tabellen ein, die du im Table Editor zusammenklickst. Tabellen, die per SQL entstehen, bekommen sie nicht, und SQL ausführen ist die Art, wie ein Builder Tabellen für dich anlegt. Die übliche Form eines Lovable-Projekts ist also: ein paar Tabellen von Hand, die geschützt sind, daneben die generierten, die es vielleicht nicht sind. Beide sehen identisch aus. Keine beschwert sich. Die App funktioniert so oder so einwandfrei, und genau das ist das Problem: Von vorne sagt dir nichts, welche Sorte du hast.

Die längere Fassung davon, mit dem SQL, steht hier, und die Anleitung in einfacher Sprache für diese Plattform ist ist deine Lovable-App sicher.

Die Policy, die den Fehler beseitigt und die Tabelle offen lässt

Row Level Security einzuschalten ist Schritt eins von zwei, und in Schritt zwei tut ein KI-Assistent bereitwillig das Falsche.

Mit der Einstellung an und ohne geschriebene Policy hört deine eigene App auf zu funktionieren. Du bekommst einen Fehler, fügst ihn in den Chat ein, und es kommt etwas zurück, das den Fehler verschwinden lässt. Sehr oft ist das eine Policy, die allen alles erlaubt, geschrieben als using (true). Sie ist eine gültige Policy. Sie erfüllt die Anforderung, dass eine Policy existiert. Sie erlaubt jede Zeile jeder Anfrage.

Das Dashboard meldet die Tabelle jetzt als geschützt, der Fehler ist weg, deine App läuft, und die Tabelle ist genauso lesbar wie vorher. Dazu haben wir einen ganzen Artikel, weil es das überzeugendste Versagen im ganzen Stack ist: RLS ist an, und deine Tabelle ist trotzdem öffentlich.

Wenn du je einen Row-Level-Security-Fehler in ein Chatfenster kopiert und den ersten Fix übernommen hast, der durchlief, lies diese Policy noch heute.

CVE-2025-48757, und warum das nicht mehr deine Frage ist

Sie ist echt, sie war ernst, und auf Lovables Seite ist sie seit über einem Jahr erledigt. Sie ist auch nicht das, wonach du suchen solltest.

Im Mai 2025 veröffentlichte der Sicherheitsforscher Matt Palmer CVE-2025-48757 zu Lovable-Apps, deren Supabase-Tabellen keine oder eine zu großzügige Row Level Security hatten. Er scannte 1.645 Lovable-Apps und fand 170 mit offenen Datenbanken. Lovables Antwort war ein Sicherheitscheck, der vor dem Veröffentlichen läuft und vor ungeschützten Tabellen warnt.

Und hier die ehrliche Lesart, und sie ist der Grund, warum die CVE der falsche Rahmen ist. Diese Veröffentlichung fand rund 10 offene Apps je 100. Sechzehn Monate später, in einer elfmal so großen Kohorte, fanden wir rund 11 je 100. Die Nenner sind nicht identisch und keine der beiden Stichproben ist das ganze Internet, nimm die zwei also als dieselbe Größenordnung und nicht als genauen Vergleich. Die Richtung ist klar genug: Die Quote ist nicht gefallen.

Das ist kein gescheiterter Fix. Es ist ein Zeichen dafür, dass es nie wirklich eine Schwachstelle in einem Produkt war. Es ist eine Einstellung an deinen eigenen Tabellen, in deinem eigenen Supabase-Projekt, die niemand sonst für dich anschalten kann. Ein Patch kommt da nicht hin, und genau deshalb kommt ein Check hin, den du selbst ausführst.

Woraus die 822 Schlüssel wirklich bestanden

Fast alle waren in Ordnung, und ein Scanner, der dir etwas anderes sagt, würde dir beibringen, ihn zu ignorieren.

822 der 18.554 Lovable-Apps hatten etwas Schlüsselförmiges im Code, den ein Besucher herunterlädt. Als Liste von Mustern gelesen sind das 4 % der Apps, die "Geheimnisse leaken". Gelesen als das, was jeder Schlüssel tatsächlich kann, sieht es so aus:

Die 727 Google-Schlüssel sind der Grund, warum wir klassifizieren statt nur zu vergleichen. Ein Google-Maps-Schlüssel im Browser ist dort, wo er hingehört, und der Fix ist, ihn auf deine eigene Domain zu beschränken, statt in Panik zu verfallen.

Auf die unteren vier Zeilen kommt es an, und sie sind selten: 30 Apps von 18.554. Sie sind auch die Funde, die von allein Geld kosten, und sie tauchen meist als Rechnung auf, bevor sie jemand bemerkt hat. Zwei Details fürs Protokoll. Alle drei service_role-Schlüssel im gesamten Scan über 30.998 Apps steckten in Lovable-Apps, und ebenso zwei der drei echten Stripe-Secrets. Ein service_role-Schlüssel im Browser macht jede Row-Level-Security-Policy in deinem Projekt in einer Zeile gegenstandslos, weshalb er der eine Fund ist, den wir auf Sicht als kritisch werten, und der, den man am selben Tag rotiert.

Die beiden Sorten auseinanderzuhalten dauert etwa eine Minute, und wir haben die Anleitung geschrieben.

Die 768 Storage-Buckets, die niemand öffnen wollte

Ein als öffentlich markierter Supabase-Bucket liefert nicht nur die Dateien aus, die deine App verlinkt. Er listet auch jede Datei darin für jeden auf, der fragt.

768 der 16.565 prüfbaren Lovable-Apps hatten mindestens einen Bucket, der seinen Inhalt auflistete. Der Grund ist derselbe wie bei den lesbaren Tabellen: Einen Bucket öffentlich zu machen ist der Weg, ein Bild sichtbar zu bekommen, es funktioniert sofort, und danach sagt dir nichts, dass die Auflistung mit dabei war. Hochgeladene Rechnungen, Ausweisfotos und Profilbilder landen alle am selben Ort. Was ein öffentlicher Bucket wirklich preisgibt erklärt den Fix, und der heißt signierte URLs und nicht ein privater Bucket, aus dem du dann selbst nicht mehr lesen kannst.

Der Fünf-Minuten-Check für deine eigene Lovable-App

Jeder Punkt ist eine Seite, die du öffnest. Nimm ein privates Fenster, damit nicht deine eigene Anmeldung für einen Fremden antwortet.

1. Supabase → Authentication → Policies. Lies die Liste durch. Jede Tabelle, bei der Row Level Security deaktiviert ist, ist für jeden lesbar, der deine Projektadresse hat, und die steht in deiner App.
2. Lies die Policies der Tabellen, bei denen sie an ist. Erlaubt eine davon allen alles, ist die Tabelle offen, und das Dashboard nennt sie trotzdem geschützt.
3. Supabase → Storage. Jeder als öffentlich markierte Bucket listet seine Dateien für jeden auf. Sieh nach, was drin ist, bevor du entscheidest, dass das in Ordnung ist.
4. Supabase → Settings → API. Prüfe, dass der Schlüssel in deiner App der veröffentlichbare ist. Wurde je ein geheimer Schlüssel ins Projekt eingefügt, rotiere ihn dort, bevor du ihn aus dem Code löschst, denn der alte Wert funktioniert bis dahin weiter.
5. Oder lass den Scan das machen. Er führt diese vier von außen aus und fünf weitere, dauert etwa 20 Sekunden, braucht kein Konto und zeigt dir eine Note und was sie verursacht hat: App scannen.

Wenn du die ganze Fläche lieber als Liste durchgehst, deckt die 10-Minuten-Sicherheitscheckliste ab, was bei jeder frisch gestarteten App bestätigt werden sollte, und kann jeder deine Supabase-Datenbank lesen ist der Test, den du machen solltest, wenn du nur eine Sache machst.

Deine App ändert sich bei jeder Veröffentlichung

Ein Scan von letztem Monat beschreibt die App von letztem Monat, und auf Lovable ist das ein kürzerer Monat als anderswo.

Veröffentlichen ist ein Klick, also ist eine Änderung live, sobald du sie annimmst. Zwischen dir und dem Internet steht kein Deploy-Schritt, der eine Tabelle abfängt, die heute Morgen ohne Row Level Security dazukam, oder einen Schlüssel, der um Mitternacht in den Chat kopiert wurde, um an einem scheiternden Build vorbeizukommen. Jede der 2.017 offenen Datenbanken, die wir gefunden haben, gehörte jemandem, dessen App einwandfrei lief.

Reeve Monitor ist die Fassung dieses Beitrags, die sich selbst ausführt. Er wiederholt alle neun Checks stündlich für bis zu drei Apps, schaut jede 60 Sekunden nach, ob die App läuft, meldet sich, wenn sich ein Ergebnis ändert, statt darauf zu warten, dass du nachsiehst, und schickt einen Monatsbericht. Er kostet €12 im Monat zum Listenpreis, mit sieben freien Tagen, bevor abgerechnet wird; die Preisseite liegt manchmal unter der Zahl hier und nie darüber.

Wenn deine Lovable-App Supabase nutzt, und 6.532 der 18.554 gescannten tun das, ist die andere Hälfte des Problems die Kopie. Eine offene Tabelle ist etwas, das ein Fremder lesen kann. Ein Agent mit Datenbankzugriff oder eine Migration, die falsch herum lief, ist etwas, das sie löschen kann, und Supabases eigenes tägliches Backup im kostenlosen Tarif ist nichts, aus dem du selbst wiederherstellen kannst. Reeve Care zieht jede Nacht eine verschlüsselte Kopie deiner Supabase-Datenbank, bewahrt sie dort auf, wo dein Projekt nicht hinkommt, prüft, dass sich jede Kopie wirklich wiederherstellen lässt, und gibt dir im Ernstfall eine Wiederherstellung per Klick. Alles aus Monitor ist enthalten. Care kostet €49 im Monat zum Listenpreis für eine App, mit denselben sieben freien Tagen.

Wie dieses zweite Versagen aussieht, erzählt von jemandem, dem es passiert ist, steht in dem Tag, an dem ein KI-Agent eine Produktionsdatenbank gelöscht hat. Keiner der neun Checks in diesem Artikel hätte dort geholfen. Eine Kopie schon.

Was du diese Woche tun solltest

Lovable hat seine Hälfte gut gemacht. Die 2.017 sind die Hälfte, die dir gehört, und sie ist eine Einstellung und keine Neufassung. Wenn du stattdessen den Vergleich über die Builder willst: welcher KI-App-Builder ist am sichersten hat die Tabelle für alle fünf.