Ist meine Lovable-App sicher?

Warum Lovable-Apps typische Lücken haben

Lovable erzeugt Code, der funktioniert. Das ist etwas anderes als Code, der abgesichert ist. Wenn du „lege eine Tabelle für Nutzerprofile an“ schreibst, entsteht die Tabelle — die Zugriffsregeln entstehen nicht mit, weil du nicht danach gefragt hast.

Dazu kommt die Bauweise: Eine Lovable-App ist eine Single-Page-App, die direkt mit Supabase spricht. Der dafür nötige Schlüssel muss im Browser liegen, er ist öffentlich und das ist auch so vorgesehen. Sicher wird das erst durch die Regeln in der Datenbank. Fehlen sie, ist der öffentliche Schlüssel ein Generalschlüssel.

Das ist kein Vorwurf an das Werkzeug. Es ist der Unterschied zwischen „es läuft“ und „es hält stand“, und den kennt man erst, wenn man ihn einmal gesehen hat.

1. Supabase-Tabellen ohne Row Level Security

Der mit Abstand folgenreichste Fehler. Ohne Row Level Security prüft Supabase bei einer Anfrage nicht, wer fragt — es liefert einfach aus. Der anon-Schlüssel, mit dem deine App fragt, steht öffentlich in deinem JavaScript.

Praktisch heißt das: Jeder, der deine Seite öffnet, die Entwicklertools aufmacht und den Schlüssel kopiert, kann deine gesamte Tabelle herunterladen. Nicht nur seine eigenen Zeilen — alle.

Genau dieses Muster ist unter CVE-2025-48757 dokumentiert, veröffentlicht am 29. Mai 2025 mit dem Schweregrad 9,3 von 10. Die offizielle Beschreibung lautet: „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."

Der Eintrag ist als „disputed“ gekennzeichnet: Lovable hält dagegen, dass die Absicherung der eigenen Daten Sache des jeweiligen Kunden sei. Dieser Einwand ist nicht unbegründet — er ändert aber nichts an der Lage, in der du dich befindest. Wenn deine Tabellen offen sind, sind sie offen, unabhängig davon, wer dafür zuständig ist.

-- In der Supabase-Konsole unter Authentication → Policies
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Eigenes Profil lesen"
  ON profiles FOR SELECT
  USING (auth.uid() = id);

2. Schlüssel, die nicht in den Browser gehören

Der Supabase-anon-Schlüssel gehört ins Frontend. Ein OpenAI-, Stripe-Secret- oder Resend-Schlüssel gehört das nicht — und landet trotzdem regelmäßig dort, weil der schnellste Weg zu einem funktionierenden Prototyp der direkte Aufruf aus dem Browser ist.

Bei Vite gilt: Alles, was mit `VITE_` beginnt, wird beim Bauen in das Bundle eingesetzt. Der Name der Variablen sagt nichts darüber aus, ob der Wert geheim ist. `VITE_OPENAI_KEY` ist genauso öffentlich wie ein Text auf deiner Startseite.

Wenn ein solcher Schlüssel einmal ausgeliefert wurde, gilt er als kompromittiert. Ihn aus dem nächsten Build zu entfernen reicht nicht — das alte Bundle war öffentlich, und Bots durchsuchen öffentliche Bundles automatisiert.

3. Source Maps in Produktion

Source Maps übersetzen das gebaute Bundle zurück in deinen Originalcode. Im Entwicklungsbetrieb sind sie unverzichtbar; öffentlich erreichbar geben sie deinen ungebauten Code preis — mit Dateinamen, Kommentaren und Ordnerstruktur.

Das ist selten direkt eine Lücke, aber es ist die Landkarte: Wer sie hat, muss nicht mehr raten, wo die Anmeldung geprüft wird oder welche Endpunkte es gibt.

// vite.config.ts
export default defineConfig({
  build: { sourcemap: false },
});

4. Fehlende Security-Header

Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy. Keiner davon macht eine Lücke auf — sie entscheiden darüber, ob aus einer kleinen Lücke eine ausgenutzte wird.

Bei Lovable-Apps fehlen sie fast immer, weil sie nicht im Anwendungscode stehen, sondern in der Auslieferungskonfiguration. Wer nie eine geschrieben hat, weiß nicht, dass es sie gibt.

Was du in fünf Minuten selbst prüfen kannst

Öffne deine App, drücke F12, gehe auf „Netzwerk“ und lade neu. Suche nach Anfragen an `supabase.co`. Kopiere eine solche Adresse samt `apikey`-Parameter und rufe sie in einem privaten Fenster auf — ohne angemeldet zu sein. Kommen Daten zurück, fehlt die Row Level Security.

Für die Schlüssel: In den Entwicklertools unter „Quellen“ das größte `.js`-Bundle öffnen und nach `sk-`, `sk_live` oder `service_role` suchen. Ein Treffer ist ein Treffer.

Diese beiden Handgriffe finden die zwei schwersten Fehler. Alles Weitere — Header, Source Maps, DNS, Abhängigkeiten, vergessene Subdomains — prüfen wir automatisch.

Häufige Fragen

Ist Lovable unsicher?

Nein. Lovable als Plattform ist nicht das Problem. Die mit Lovable erzeugten Apps sind aber im Auslieferungszustand nicht abgesichert: Row Level Security ist nicht aktiv, Security-Header fehlen, und Schlüssel landen leicht im Frontend. Das sind Einstellungen, keine Fehler im Werkzeug.

Reicht es, wenn Claude oder Cursor meinen Code geprüft haben?

Das hilft, deckt aber etwas anderes ab. Ein KI-Assistent liest deinen Quellcode. Wir prüfen, was dein Server tatsächlich ausliefert — das ist nicht dasselbe. Im Code steht `import.meta.env.VITE_STRIPE_KEY`, was harmlos aussieht; erst der Build setzt den echten Wert ein. Und ob deine Supabase-Regeln greifen, steht in der Datenbank, nicht im Repository.

Wie finde ich heraus, ob meine Supabase-Tabellen offen sind?

Rufe eine REST-Adresse deines Projekts mit dem öffentlichen anon-Schlüssel in einem privaten Browserfenster auf, ohne angemeldet zu sein. Kommen Datensätze zurück, ist die Tabelle ohne Anmeldung lesbar. Unser Deep-Scan macht genau das — nach einem Nachweis, dass die Domain dir gehört.

Kann ich meine Lovable-App kostenlos prüfen lassen?

Ja. Der Scan ist kostenlos und braucht kein Konto. Du siehst, wie viele Befunde es gibt, wie schwer sie wiegen und in welchem Bereich sie liegen; einen Teil der leichteren Befunde zeigen wir vollständig. Der vollständige Bericht mit allen Fundstellen kostet einmalig 9,49 Euro pro Domain.