Lovable Security Scan: das Eine, was er nicht beweist

Du klickst bei deiner Lovable-App auf Publish, und bevor sie rausgeht, läuft ein Scan. Ein paar Sekunden später kommt er sauber zurück, oder mit einer Liste, und in beiden Fällen hältst du ein Ergebnis in der Hand, das du nicht einschätzen kannst. Ist das alles? Reicht das, um echte Menschen darauf zu lassen?

Und hier liegt der Punkt, den du vor der Entscheidung kennen solltest: der Lovable Security Scan und ein Scan deiner veröffentlichten App lesen zwei verschiedene Dinge. Der eine liest die Schlösser und die Verkabelung. Der andere geht hin und drückt die Klinke. Beide lohnen sich, und nur der zweite macht das, was jeder Besucher deiner App den ganzen Tag macht.

Prüft Lovable meine App auf Sicherheitsprobleme?

Ja, und es sind zwei davon. Beide sind kostenlos.

Der Quick Scan läuft bei jeder Veröffentlichung von selbst und ist in Sekunden fertig. Der Deep Scan liest deinen gesamten Anwendungscode, und du startest ihn selbst. Beide lesen dein Projekt von innen: deine Datenbankeinstellungen, die Zugriffsregeln an deinen Tabellen, deinen Abhängigkeitsbaum, deinen Code.

Alles Folgende stammt aus Lovables eigener Sicherheitsdokumentation, gelesen am 24. September 2026. Diese Funktion hat sich in einem Jahr mehr als einmal geändert, also achte bei jedem Artikel darauf, von wann er ist, diesem hier eingeschlossen.

Was der Lovable Security Scan prüft

Drei Bereiche, als fester Satz Prüfungen, in Sekunden, bei jeder Veröffentlichung.

Lovables Dokumentation nennt sie eine Datenbankprüfung, ein Abhängigkeits-Audit und eine MCP-Server-Prüfung. Die Datenbankprüfung ist die für diesen Artikel entscheidende, und ihre Beschreibung lohnt genaues Lesen: Sie deckt Tabellen ohne Zugriffskontrolle pro Datensatz ab, also ohne Row Level Security, außerdem Zugriffsregeln, die jeden durchlassen, und abgeschalteten Schutz gegen geleakte Passwörter. Das Abhängigkeits-Audit sucht nach bekannten Schwachstellen in deinen npm-Paketen. Die MCP-Prüfung sucht nach einem MCP-Server, den deine App ohne Authentifizierung nach außen gibt.

Funde kommen nach Bereich gruppiert zurück und tragen die Kennzeichnung Critical, Warning oder Info. Der Scan startet automatisch aus dem Publish-Dialog, und du kannst ihn außerdem in der Security-Ansicht des Projekts auslösen.

Manche Beiträge nennen das den Basic Scan. Die Schaltfläche in der Security-Ansicht heißt heute Run quick scan, und wenn ein Artikel und dein Bildschirm sich beim Namen uneinig sind, ist dein Bildschirm der aktuelle.

Was der Deep Scan zusätzlich tut

Er liest deinen gesamten Anwendungscode, und er startet nicht von selbst.

Der Deep Scan enthält alles aus dem Quick Scan und schaut danach auf deine eigene Logik, deine Berechtigungen und deine Daten. Lovable nennt sieben Bereiche: Zugriffskontrolle und Autorisierung, unauthentifizierte und missbrauchbare Endpunkte, unsichere Eingaben und Injection, geleakte Geheimnisse und Zugangsdaten, Zahlungen und Abrechnung, Authentifizierung und Kontosicherheit sowie offengelegte personenbezogene und sensible Daten. Er ist ebenfalls kostenlos.

Der Satz in der Dokumentation, nach dem du wirklich handeln solltest, ist dieser: Der Deep Scan läuft beim Arbeiten nicht automatisch. Er läuft, wenn du ihn laufen lässt. Bei einem Projekt, in dem nie einer lief, wurde nie der Code gelesen, egal wie oft es veröffentlicht wurde, und der Publish-Dialog sagt dir das nicht. Enterprise-Workspaces können Deep Scans über ausgewählte Projekte hinweg im Workspace Security center planen, und das ist die eine Konstellation, in der es ohne das Gedächtnis eines Menschen passiert.

Lovable kann auch selbst Korrekturen versuchen, während du baust oder über Try to fix all in der Security-Ansicht. Lies nach, was eine Korrektur geändert hat, bevor du sie übernimmst. Die Reparatur, die einen Row-Level-Security-Fehler verschwinden lässt, ist sehr oft eine Policy, die jeden durchlässt, und diese Policy erfüllt die Prüfung und lässt die Tabelle offen.

Die Kritik von 2025, und was sich geändert hat

Die erste Fassung dieser Prüfung sagte dir, dass eine Policy existiert. Sie sagte dir nicht, ob die Policy funktioniert, und der Forscher, der das ursprüngliche Problem fand, hat das damals selbst geschrieben.

Im Mai 2025 veröffentlichte Matt Palmer CVE-2025-48757 über Lovable-Apps, deren Supabase-Tabellen keine oder eine zu großzügig geschriebene Row Level Security hatten. Lovable antwortete darauf mit der Prüfung vor dem Veröffentlichen. Palmers eigener Text beschrieb ihre Grenze in einem Klammersatz:

Lovables Publish-Funktion hilft sicherzustellen, dass RLS-Policies in allen Tabellen aktiviert sind, und meldet, wenn nicht (zeigt aber nicht unbedingt an, ob sie ausreichend sind).

Auf diese Lücke gibt die heutige Dokumentation eine Antwort: Sie nennt Zugriffsregeln, die jeden durchlassen, ausdrücklich als etwas, das die Datenbankprüfung meldet. Nichts in diesem Artikel prüft diese Angabe nach. Wenn du sie nachprüfen willst, leg eine Wegwerftabelle mit einer Policy an, die jeden durchlässt, und schau, ob der Scan sie benennt. Die ausführliche Fassung des CVE steht in ist Lovable sicher.

Was ein Scan von innen nicht beweisen kann

Ob deine laufende App Zeilen an jemanden herausgibt, der nicht angemeldet ist.

Ein Schloss kann eingebaut, erfasst und in der Zeichnung korrekt sein, und die Tür geht trotzdem auf. Eine Policy ist eine Aussage darüber, was passieren soll; was tatsächlich passiert, entscheidet eine Anfrage. Drei Wege, auf denen eine Regel als vorhanden gilt und die Tabelle trotzdem antwortet:

• Die Policy lässt jeden durch. Geschrieben als using (true), ist sie eine gültige Policy, sie erfüllt die Anforderung, dass eine existiert, und sie gibt jede Zeile an jeden Aufrufer zurück.
• Die Policy deckt Lesen ab und sonst nichts. Das Auswählen wird geprüft, Einfügen und Ändern und Löschen wurden nie geschrieben, also kann jeder in eine Tabelle schreiben, die niemand vollständig lesen kann.
• Die Bedingung trifft auf mehr Leute zu als gedacht. Sie sollte einen einzigen Kunden benennen und benennt jeden angemeldeten Besucher, oder jeden Besucher.

Jetzt der Teil, der darüber entscheidet, wie du ein grünes Ergebnis lesen solltest. Von außen geben diese drei und eine Tabelle ganz ohne Schutz dieselbe Antwort, nämlich Zeilen. Deine Nutzer können sie nicht auseinanderhalten. Alle anderen, die deine App öffnen, auch nicht.

Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Checks über 30.998 laufende Apps laufen lassen, und 18.554 davon waren auf Lovable veröffentlicht. Von den Lovable-Apps, die ein Supabase-Projekt benannten, antworteten 3.553 klar genug für ein Urteil, und 2.017 davon gaben Zeilen an eine Anfrage heraus, die überhaupt keine Anmeldung trug. Die Methode und jeder Nenner stehen im Bericht.

Eine Ehrlichkeitsschranke zu dieser Zahl. Wir standen auf dem Gehweg, und wir haben keinen Blick in eines dieser Projekte. Wir können berichten, was 2.017 veröffentlichte Apps geantwortet haben. Wir können nicht berichten, wie viele davon einen Scan laufen ließen oder was er ihnen sagte.

Deine eigene App beantwortet dieselbe Frage in etwa 20 Sekunden, und du musst uns nicht glauben, auf welcher Seite der 2.017 sie steht: App scannen. Der Scan fragt jede Tabelle nach der Anzahl der Zeilen, die ein Aufrufer ohne Anmeldung bekäme, liest die Zahl und hört dort auf, ohne eine Zeile zu holen.

Was ein Scan von außen nicht sehen kann

Die Klinke zu drücken sagt dir nichts über einen Raum, der keine Tür zur Straße hat, und davon gibt es vier.

Dein npm-Abhängigkeitsbaum steckt nicht in der Seite, die ein Browser lädt. Dein serverseitiger Code, einschließlich Edge Functions und der Frage, ob eine Route prüft, wer da ruft, läuft an einem Ort, den wir nie erreichen. Eine Tabelle, die dein Frontend nie benennt, ist für uns unsichtbar, denn wir finden Tabellennamen im Code, den deine App ausliefert, plus eine kurze Liste üblicher Namen, also wird eine Tabelle, die im Browser nirgends vorkommt und die niemand raten würde, nicht gefragt. Und ein MCP-Server ist nichts, was eine Seitenanfrage findet.

Lovables zwei Scans lesen zusammen alle vier. Unserer schreibt "Konnte nicht geprüft werden", wenn er eine Frage nicht beantworten konnte, statt eines Häkchens.

Die Zeile darüber, was deine veröffentlichte App einem Fremden aushändigt, ist der Grund, beide laufen zu lassen, und um sie herum ist unser Scan gebaut. Die allgemeine Fassung davon, wo der Blick von außen endet, steht in was ein URL-Scan übersieht.

Beide, und in dieser Reihenfolge

Der Scan von innen vor dem Veröffentlichen, der von außen danach, weil die beiden Dinge in dieser Reihenfolge passieren.

1. Lass den Quick Scan beim Veröffentlichen laufen und lies ihn dann. Es sind ein paar Sekunden, und er passiert ohnehin. Am Dialog vorbeizuklicken ist der häufigste Weg, auf dem ein Critical-Fund in Produktion landet.
2. Starte einen Deep Scan, bevor etwas Echtes live geht, und noch einmal, nachdem du Anmeldung, Zahlungen oder eine Tabelle mit Personen hinzugefügt hast. Von selbst läuft er nicht.
3. Veröffentlichen.
4. Scanne die veröffentlichte Adresse von außen. Unserer liest deine laufende App so, wie ein Besucher es tut, dauert etwa 20 Sekunden, braucht kein Konto und benennt die Prüfungen, die er nicht abschließen konnte: App scannen.

In dieser Abfolge steckt eine Lücke, und mit der lohnt es sich zu planen. Der Quick Scan läuft, wenn du veröffentlichst. Das meiste, was eine Tabelle öffnet, geht gar nicht durchs Veröffentlichen: Du änderst eine Einstellung im Supabase-Dashboard, du übernimmst um Mitternacht eine Policy, die dir ein Assistent ins Chatfenster geschrieben hat, du legst heute früh eine Tabelle an und die Seite, die sie liest, geht am Donnerstag raus. Nichts davon ist eine Veröffentlichung, also startet nichts davon einen Scan, und der Deep Scan wäre ohnehin nie von selbst gelaufen.

Reeve Monitor übernimmt die Hälfte von außen an den Tagen, an denen du nicht daran denkst. Er lässt alle neun Checks stündlich auf bis zu drei Apps laufen, beobachtet, ob deine App überhaupt antwortet, sagt dir Bescheid, wenn sich ein Ergebnis ändert, statt zu warten, bis du nachsiehst, und schickt am Monatsende einen Bericht.

Ein grünes Ergebnis lesen

Ein sauberes Ergebnis heißt, dass jede Frage, die dieser Scan stellen konnte, an dem Tag sauber zurückkam. Das ist etwas wert, und es ist kein Urteil über deine App.

Lovable schreibt denselben Vorbehalt in die eigene Dokumentation: Die Werkzeuge helfen dabei, verbreitete Sicherheitsprobleme zu finden, und können keine vollständige Sicherheit garantieren. Unserer trägt ihn ebenfalls, denn eine automatische externe Prüfung ist kein Audit, und eine leere Fundliste ist keine Garantie.

Die eine Regel für den Fall, dass die beiden nicht übereinstimmen: Wenn der Scan von innen sauber ist und ein Scan von außen sagt, eine Tabelle habe auf eine Anfrage ohne Anmeldung geantwortet, handle nach der Antwort von außen. Diese Antwort bekommen deine Nutzer, und alle anderen bekommen sie auch. Geh hin und lies die Policy an dieser Tabelle.

Wenn deine App auf Supabase läuft, ist die Anleitung in Alltagssprache für diese Plattform ist deine Lovable-App sicher, und die Prüfungen als Befehle zum Selbstausführen stehen in der Supabase-Sicherheitsprüfung.

Was du diese Woche tun solltest

Wenn deine Lovable-App Supabase nutzt, öffne ein privates Browserfenster und geh noch vor Freitag die Liste unter Authentication und Policies durch. Kann jeder deine Supabase-Datenbank lesen ist derselbe Test, aufgeschrieben als Befehle zum Einfügen in ein Terminal.