Reeve Ist deine Lovable-App sicher?
Ist Lovable sicher genug zum Bauen? Meistens ja. Entschieden wird es von einer Datenbank-Einstellung aus dem Moment der Tabellenerstellung, heute prüfbar.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine Lovable-App ist auf der Code-Seite meistens sicher. Ob deine Daten sicher sind, entscheidet eine Supabase-Einstellung pro Tabelle.
- Einen API-Schlüssel in deiner App zu finden ist normalerweise in Ordnung. Ein öffentlicher Schlüssel gehört dorthin; sb_secret_… oder service_role nicht.
- Supabase schaltet Row Level Security für Tabellen aus dem Table Editor ein, aber nicht für Tabellen, die per SQL entstehen, und genau so legt ein Builder sie an.
Lovable bringt dich schneller von der Idee zur laufenden App als alles andere, und der Teil, den es für dich übernimmt, ist genau der, den du nie zu Gesicht bekommst: die Datenbank, die Tabellen, die Regeln darüber, wer sie lesen darf. Wenn dir jemand sagt, deine Lovable-App „verliere Daten", liegt die Antwort meist genau dort, und dorthin kannst du aus dem Editor heraus nicht schauen.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Das Risiko ist fast nie der Code, den Lovable für dich geschrieben hat. Es ist eine einzige Datenbank-Einstellung, festgelegt in dem Moment, in dem eine Tabelle entstand, und die meisten Texte überspringen sie oder beschreiben sie verkehrt herum.
Was Lovable tatsächlich baut, und welche Hälfte öffentlich ist
Zwei Hälften, und nur eine davon ist privat.
Stell es dir als Laden vor. Lovable baut dir eine Ladenfront: die Seiten, die Schaltflächen, die Formulare, und diese Ladenfront wird jedem Besucher vollständig ausgehändigt. Jeder kann sie lesen. Das ist kein Mangel; ein Browser kann keine Seite anzeigen, die er nicht bekommen hat. Hinter der Ladenfront liegt ein Lager, deine Supabase-Datenbank, und das ist ein eigenes Gebäude mit eigenem Schloss.
Der Fehler, der Leute etwas kostet, ist die Annahme, die Ladenfront steuere das Lager. Tut sie nicht. Eine Schaltfläche aus deiner App zu entfernen heißt, ein Schild abzunehmen, nicht eine Tür abzuschließen. Deine Datenbank ist direkt über das Internet erreichbar, für jeden, der ihre Adresse hat, und diese Adresse steht auf der Ladenfront, weil deine eigene App genau so mit ihr spricht.
Ist ein Schlüssel im Code deiner Lovable-App ein Problem?
Meistens nicht. Es hängt vollständig davon ab, welcher Schlüssel es ist, und es gibt zwei Sorten, die fast identisch aussehen.
Ein öffentlicher Schlüssel sagt, zu welchem Projekt eine Anfrage gehört, und
sonst nichts. Supabase nennt ihn in neuen Projekten sb_publishable_… und in
älteren anon, und er ist dafür gemacht, in deiner App zu liegen, wo ihn jeder
lesen kann. Ein geheimer Schlüssel ist das Gegenteil: sb_secret_…, oder
service_role in älteren Projekten. Er ignoriert jede Regel, die du gesetzt
hast, und kann jede Zeile in jeder Tabelle lesen und schreiben.
Die beiden liegen im Supabase-Dashboard direkt nebeneinander, sind gleich lang und verhalten sich beim Bauen identisch. Den falschen zu kopieren ist ein einziger verrutschter Klick, und danach geht nichts kaputt, und genau deshalb fällt es nicht auf. Wenn du die ausführliche Fassung willst, wie man sie unterscheidet, wir haben eine geschrieben.
Was entscheidet, ob Fremde deine Daten lesen können
Row Level Security, ein Schalter pro Tabelle in Supabase, der Zeile für Zeile entscheidet, wer was sehen darf. Ist er aus, liest dein öffentlicher Schlüssel die ganze Tabelle. Ist er an und eine Policy geschrieben, liest er nur die Zeilen, die diese Policy erlaubt.
Jetzt der Teil, der speziell für eine Lovable-App zählt. Supabase aktiviert Row Level Security standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, dem zum Klicken. Tabellen, die per SQL angelegt werden, bekommen sie nicht aktiviert und müssen bewusst eingeschaltet werden.
Per SQL legt ein Builder Tabellen für dich an.
Die übliche Gestalt eines Lovable-Projekts ist also eine Handvoll Tabellen, die du durch Klicken hinzugefügt hast und die geschützt sind, neben den Tabellen, die für dich generiert wurden und es womöglich nicht sind. Beide sehen im Editor gleich aus. Keine wird sich beschweren. Und die Einstellung einzuschalten ist noch nicht die Ziellinie, denn eine Tabelle mit aktivierter Row Level Security und einer Policy, die alle durchlässt, ist offen und liest sich als geschlossen.
So prüfst du deine eigene Lovable-App in etwa zehn Minuten
Öffne Supabase, dann Authentication → Policies. Geh die Tabellenliste durch. Alles, was als „Row Level Security deaktiviert" markiert ist, kann jeder lesen, der deine Projektadresse hat, und die ist öffentlich.
Prüfe den Schlüssel, den deine App ausliefert. Geh in Supabase auf Settings → API. Ist es der öffentliche Schlüssel, ist alles richtig und nichts zu tun. Wurde je ein geheimer Schlüssel in dein Lovable-Projekt eingefügt, tausche ihn dort zuerst aus, denn ihn aus dem Code zu löschen schließt die Tür nicht, weil der alte Wert noch in jeder zwischengespeicherten Kopie deiner Seite steckt.
Sieh dir deine Storage-Buckets an. Alles, was als öffentlich markiert ist, kann jeder auflisten und herunterladen, ob deine App darauf verlinkt oder nicht.
Und dann schau von außen. Die Prüfungen oben sagen dir, was eingestellt ist; sie sagen dir nicht, was ein Fremder tatsächlich erreicht. Genau diese Lücke füllt unser kostenloser Scan: Er liest deine Live-Seite so, wie es jeder Besucher täte, und gibt dir in etwa 20 Sekunden eine Note, ganz ohne Konto: App scannen.
Was zu tun ist
- Die Ladenfront ist von Natur aus öffentlich. Alles, was Lovable an einen Browser ausliefert, kann jeder lesen, und kein Verstecken ändert das.
- Ein öffentlicher Schlüssel in deiner App ist richtig. Ein geheimer Schlüssel (
sb_secret_…oderservice_role) ist der, den du heute austauschst. - Tabellen aus Supabases Table Editor haben Row Level Security standardmäßig an. Tabellen, die per SQL entstehen, nicht, und genau so legt ein Builder sie an.
- Row Level Security einzuschalten ist Schritt eins. Eine Policy, die alle erlaubt, lässt die Tabelle offen, während das Dashboard sie als geschützt meldet.
- Einen Bildschirm oder eine Schaltfläche aus deiner Lovable-App zu entfernen ändert nichts daran, was deine Datenbank beantwortet.
Das Schnellste mit echtem Nutzen, das du heute tun kannst: Öffne in Supabase Authentication → Policies und lies die Liste. Steht bei einer Tabelle, dass Row Level Security deaktiviert ist, fang mit der an, und wenn du die ganze Fläche lieber als Liste durchgehst, deckt die Sicherheits-Checkliste in 10 Minuten den Rest ab.
Was bei einer Lovable-App tatsächlich schiefgehen kann
Nichts davon bedeutet, dass du etwas falsch gemacht hast. Es sind die normalen Nebenwirkungen von schnellem Bauen. Hier die, die eine Prüfung wert sind:
Ein geheimer Schlüssel im Browser gelandet
Ein „geheimer Schlüssel“ ist das Master-Passwort für einen Dienst, den du nutzt: deine Datenbank, ein E-Mail-Tool, eine KI-API. Er soll auf einem Server leben. Manchmal rutscht einer in den Code, der im Browser deines Besuchers läuft, wo ihn jeder lesen kann, und jemand könnte ihn nutzen, um an deine Daten zu kommen oder in deinem Namen Kosten zu verursachen. Die Nuance: Manche Schlüssel sollen öffentlich sein (Lovable und Supabase nennen diese „publishable“- oder „anon“-Schlüssel), und die sind in Ordnung. Reeve kennt den Unterschied, sodass ein sicherer Schlüssel nie einen Fehlalarm auslöst.
Deine Datenbank offen gelassen (Supabase-RLS aus)
Lovable-Apps speichern Daten meist in Supabase. Supabase hat einen Sicherheitsschalter namens Row Level Security (RLS), der entscheidet, wer jede Zeile lesen oder ändern darf. Ist er aus, können deine Tabellen von jedem lesbar, oder änderbar, sein, der die Adresse findet. Das ist der Unterschied zwischen „meine Daten gehören mir“ und „meine Kundenliste ist öffentlich“, und es ist das häufigste Problem in Vibe-Coding-Apps.
Eine offengelegte .env- oder Konfigurationsdatei
Die .env-Datei ist der Ort, an dem ein Projekt seine Passwörter und Schlüssel aufbewahrt. Ab und zu wird sie versehentlich zusammen mit der App veröffentlicht. Ist sie erreichbar, ist sie eine Abkürzung direkt zu allem Sensiblen. Reeve prüft, ob deine still zugänglich ist.
Öffentlicher Dateispeicher
Wenn deine App Leuten erlaubt, Dateien hochzuladen (Fotos, PDFs), leben diese in Speicher-„Buckets“. Ein öffentlich gelassener Bucket bedeutet, dass jeder durchsehen oder herunterladen kann, was drin ist, sodass ein Upload, der für eine Person gedacht war, für alle sichtbar werden kann. Reeve prüft, ob deine Buckets auflistbar sind; es lädt nie die Dateien von jemandem herunter.
Source Maps eingeschaltet gelassen
Eine „Source Map“ ist eine Hintergrund-Datei, die den Original-Code deiner App offenlegt. Praktisch beim Bauen, aber wenn sie in die Produktion geht, gibt sie Fremden eine lesbare Kopie davon, wie deine App funktioniert, was jede Tür oben leichter auffindbar macht. Allein nicht dringend, aber es lohnt sich, aufzuräumen.
Fehlende Sicherheits-Header & offene Endpunkte
Kleine Einstellungen, die Browsern sagen, wie sie deine Besucher schützen sollen, plus ob die Daten-Endpunkte deiner App jedem oder jeder Website antworten. Einzeln geringfügig; zusammen vergrößern sie die Lücke. Reeve markiert die, die fehlen.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Hausinspektor, der ums Gebäude geht und die Türen probiert. Sie ist schnell und fängt die häufigen, folgenreichen Fehler ab. Sie ist kein vollständiges Sicherheitsaudit, und eine saubere Note ist keine Garantie. Sie bedeutet, dass die offensichtlichen Türen zu sind.
Lovable ist ein starkes Werkzeug, und sein Team fügt laufend Sicherheits-Leitplanken hinzu; Supabase hat außerdem einen eingebauten Berater, der RLS-Probleme in seinem Dashboard meldet. Beides ist wirklich nützlich. Was Reeve ergänzt: Du lebst in Lovable, nicht in der Supabase-Konsole, und diese Werkzeuge sprechen Entwickler. Reeve betrachtet deine ganze App von außen, so, wie es ein Fremder täte, und sagt dir in Worten, mit denen du etwas anfangen kannst, was es findet. Und wenn du am liebsten gar nicht daran denken möchtest, können wir sie für dich im Blick behalten.
Willst du es erledigt, nicht nur geprüft?
Reeve Care behält deine App im Blick, sichert deine Daten und hilft dir, Dinge zu reparieren, wenn sie kaputtgehen, damit du weiterbauen kannst, statt dir Sorgen zu machen.
Mehr über Reeve Care erfahrenFAQ
Ist meine Lovable-App standardmäßig sicher?
Lovable gibt dir einen soliden Ausgangspunkt und verbessert seine Voreinstellungen laufend, aber „standardmäßig sicher“ hängt trotzdem davon ab, wie deine App eingerichtet ist, besonders von deinen Supabase-Datenbankregeln. Der einzige Weg, es zu wissen, ist zu prüfen, was tatsächlich offengelegt ist, und genau das macht Reeves kostenloser Scan in etwa 20 Sekunden.
Kann eine Lovable-App meine API-Schlüssel leaken?
Es kann passieren, meist wenn ein Schlüssel, der auf einen Server gehört, im Frontend-Code landet. Aber nicht jeder Schlüssel ist ein Problem: Manche sind dafür gemacht, öffentlich zu sein. Reeve liest den geladenen Code deiner App, findet alle Schlüssel und sagt dir, welche sicher sind und welche umziehen müssen.
Was ist Supabase-RLS und warum ist es für meine Lovable-App wichtig?
RLS (Row Level Security) ist Supabases Regel dafür, wer jede Zeile deiner Daten sehen oder ändern darf. Ist sie aus, können deine Tabellen für jeden offen sein. Da die meisten Lovable-Apps Supabase nutzen, ist es das Wichtigste, das man richtig machen muss, und Reeve prüft es, ohne je deine tatsächlichen Daten zu lesen.
Bricht das Scannen meiner Lovable-App etwas oder ändert meine Daten?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es loggt sich nie ein, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, wie das Prüfen, ob eine Tür abgeschlossen ist, ohne einzutreten.
Lovable hat meine Datenbank für mich gebaut. Heißt das, sie ist sicher eingerichtet?
Nicht automatisch, und der Grund ist ein sehr konkreter. 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 per SQL legt ein Builder Tabellen für dich an. Die Tabellen, die du selbst gemacht hast, sind also meist geschützt, und die von Lovable erzeugten womöglich nicht.
Bei welchen meiner Tabellen ist Row Level Security eingeschaltet?
Öffne dein Supabase-Projekt, geh auf Authentication und dann Policies. Dort steht jede Tabelle deines public-Schemas mit der Angabe, ob RLS aktiv ist. Alles, was als deaktiviert angezeigt wird, ist für jeden lesbar, der deine Projekt-URL und deinen öffentlichen Schlüssel hat, und beides steckt in deiner App.
Ich habe einen Schlüssel in meiner Lovable-App gefunden. Woran erkenne ich, ob er zählt?
Lies, was für einer es ist. Ein öffentlicher Schlüssel (in neuen Supabase-Projekten sb_publishable_, in älteren anon) gehört in den Browser und ist kein Leck. Ein geheimer Schlüssel, sb_secret_ oder das ältere service_role, ignoriert jede Regel, die du setzt, und darf nie in einen Browser gelangen. Findest du den, tausche ihn im Supabase-Dashboard aus, bevor du sonst etwas tust.