Sicherheit und Sichtbarkeit für deine Lovable-App

„Lovable-Sicherheit" sind zwei Dinge, die man auseinanderhalten sollte. Das erste ist das Lovable-Projekt selbst: was du in den Chat einfügst, wo es Geheimnisse speichert, wer dein Projekt sehen kann und wo die App am Ende deployed wird. Das zweite ist der Code, den Lovable erzeugt, eine React-SPA auf Supabase, die immer dieselben fünf oder sechs Fehler mitbringt. Dieser Guide deckt beides ab, mit einem Anweisungsblock für die Knowledge-Sektion deines Projekts, einem Review-Prompt vor dem Veröffentlichen und der Methode, das Ergebnis von außen zu prüfen.

Teil 1: Dein Lovable-Projekt absichern

Was du in den Chat einfügst, bleibt dort

Der Projekt-Chat ist die Geschichte deiner App: jeder Prompt, jeder Schlüssel, den du „damit es läuft" eingefügt hast, und jede Antwort. Gelangt ein geheimer Schlüssel über den Chat hinein, schreibt das Modell ihn gern direkt in den Frontend-Code, und von dort reist er im Bundle zu jedem Besucher. Die Regel ist einfach: Schlüssel kommen nie über den Chat hinein. Wenn Lovable dich für die Anbindung eines Dienstes nach einem Geheimnis fragt, nutz das angebotene Secrets-Feld; das speichert es als Variable der Supabase Edge Functions, serverseitig, und der erzeugte Code liest es mit Deno.env.get.

Geheimnisse: Server ja, Browser nein

Lovable kann mit einer Integration zwei Dinge tun: sie aus dem Browser oder aus einer Edge Function aufrufen. Das erste ist richtig für öffentliche Schlüssel (Supabases anon, Stripes publishable, eine Projekt-ID). Das zweite ist die einzige Option für geheime Schlüssel (OpenAI, Resend, Stripes secret, der service_role). Wenn du eine Funktion anforderst und das Ergebnis den Dienst aus einer React-Komponente mit dem Schlüssel darin aufruft, verlang ausdrücklich, ihn in eine Edge Function zu verschieben. Mehr in Geheimnisse, die deine App im Browser preisgibt.

Sichtbarkeit von Projekt und Code

Ein öffentliches Projekt auf Lovable legt Code und Prompt-Verlauf für jeden mit dem Link offen, einschließlich jedes Schlüssels, den du je eingefügt hast. Prüf die Sichtbarkeit in den Projekteinstellungen und, falls du die GitHub-Synchronisation aktiviert hast, ob das Repository privat ist. War ein Schlüssel je in einem öffentlichen Projekt oder Repository, betrachte ihn als kompromittiert und rotiere ihn.

Wo die veröffentlichte App lebt

Lovable veröffentlicht auf einer .lovable.app-Subdomain oder deiner eigenen Domain. Dieses Hosting lässt dich keine Sicherheits-Header und keine eigenen Weiterleitungen konfigurieren. Für viele Apps reicht das; brauchst du Content-Security-Policy, HSTS oder Cache-Regeln, exportiere nach GitHub und deploye auf Vercel oder Netlify mit deren Konfigurationsdatei. Bedenk auch, dass die Preview-URL jeder Version für jeden erreichbar ist, der sie hat.

Supabase gehört dir, nicht Lovable

Wenn du Supabase anbindest (oder Lovables verwaltetes Backend nutzt, das darunter Supabase ist), legt Lovable Tabellen, Policies und Funktionen für dich an. Aber RLS, Buckets und Auth-Einstellungen bleiben deine Verantwortung. Lovable hat nach der CVE-2025-48757 eine Sicherheitsprüfung vor dem Veröffentlichen ergänzt; nimm sie als ersten Filter, nicht als Garantie, und geh den Sicherheits-Guide für Supabase durch, der drei SQL-Abfragen enthält, um das Projekt in einer Minute zu prüfen.

Teil 2: Die Fehler, die Lovable in deinen Code einbaut

• Tabellen ohne RLS oder mit using (true)-Policies. Der Ursprung der CVE und der schwerste Fehler. Jeder mit dem anon-Schlüssel liest und schreibt deine Daten.
• Rechteprüfungen nur im Frontend. Eine /admin-Route, die nur den Button versteckt, wenn der Nutzer kein Admin ist. Der Server (RLS oder die Edge Function) muss es ebenfalls prüfen, denn die API lässt sich ohne die Oberfläche aufrufen.
• Edge Functions ohne Authentifizierung oder Limit. Das Template antwortet jedem, mit Access-Control-Allow-Origin: *, und wenn es OpenAI aufruft oder E-Mails versendet, kann jeder dein Kontingent verbrauchen. Verlange das JWT des Nutzers, beschränke den Origin und deckle Anfragen pro Nutzer.
• Öffentliche Buckets für Nutzerdateien. Lovable legt den Bucket öffentlich an, damit Bilder „angezeigt werden". Für private Dokumente: privater Bucket und signierte URLs.
• Unsichtbar für KI und Suchmaschinen. Die App ist eine Vite-SPA: Das HTML kommt leer an, und die Bots von ChatGPT oder Perplexity sehen nichts. Wenn Landingpage und Blog zählen, trenn sie von der App. Details in warum mit KI gebaute Apps für die KI unsichtbar sind.
• Keine Sicherheits-Header, keine Metadaten. Weder CSP noch HSTS noch X-Frame-Options, und der Titel ist der des Templates. Ersteres erfordert ein Deployment außerhalb von lovable.app; Letzteres löst ein Prompt.
• Validierung nur im Formular. Das Feld hat maxLength, aber die Edge Function oder die Tabelle nehmen, was kommt. Validiere auch auf dem Server und in den Datenbank-Constraints.

Ein Block für die Knowledge-Sektion deines Projekts

In den Projekteinstellungen hat Lovable eine Wissens-Sektion, die das Modell bei jeder Anfrage liest. Füg das ein, damit die Regeln ab dem ersten Prompt gelten:

Sicherheitsregeln dieses Projekts:
- Jede neue Tabelle hat RLS aktiviert und eine explizite Policy pro Operation. Nutze nie using (true) oder with check (true), außer bei öffentlichen Nur-Lese-Inhaltstabellen, und sag es mir, wenn du es tust.
- Schreib nie geheime Schlüssel in Frontend-Code. Integrationen mit geheimen Schlüsseln kommen in eine Edge Function, die das Geheimnis mit Deno.env.get liest.
- Jede Edge Function prüft das JWT des Nutzers, sofern ich nichts anderes sage, beschränkt Access-Control-Allow-Origin auf unsere Domain und validiert die Eingabe.
- Admin-Rechte werden in RLS oder auf dem Server geprüft, nie nur im Frontend.
- Von Nutzern hochgeladene Dateien kommen in private Buckets mit Policies und signierten URLs.
- Die Spalten role, is_admin, plan und credits sind vom Nutzer nicht editierbar.
- Setz einen echten Titel, eine echte Meta-Description und echte Open-Graph-Tags in die index.html.

Ein Review-Prompt vor dem Veröffentlichen

Prüfe die Sicherheit dieses Projekts und ändere noch nichts. Antworte mit einer Liste:
1. Tabellen ohne RLS und Policies mit using (true) oder with check (true).
2. Schlüssel oder Tokens im Frontend-Code, mit Datei und Zeile.
3. Edge Functions, die das JWT nicht prüfen, mit Access-Control-Allow-Origin: * antworten oder die Eingabe nicht validieren.
4. Admin-Routen oder -Aktionen, die nur im Frontend geschützt sind.
5. Öffentliche Buckets mit Nutzerdateien.
6. Privilegspalten, die ein Nutzer ändern kann.
7. Metadaten in der index.html, die noch vom Template stammen.
Schlag für jeden Punkt die exakte Änderung vor und warte auf meine Bestätigung.

Prüf das Ergebnis von außen

Öffne deine veröffentlichte App in einem Inkognito-Fenster, Rechtsklick, „Seitenquelltext anzeigen", und such in den geladenen JavaScript-Dateien nach service_role, sk_live, sk- und Bearer. Dann teste die Supabase-API ohne Sitzung:

curl -s "https://DEIN_PROJEKT.supabase.co/rest/v1/profiles?select=*" -H "apikey: DEIN_ANON_KEY" -H "Authorization: Bearer DEIN_ANON_KEY"

Kommen Zeilen zurück, ist diese Tabelle offen. Scanaris macht das und rund vierzig weitere Prüfungen in 30 Sekunden: Es erkennt, dass die App mit Lovable gebaut ist, testet die Supabase-Tabellen ohne Sitzung, sucht Geheimnisse im Bundle, prüft Header, Cookies, CORS und offengelegte Dateien und kontrolliert, ob dein Inhalt ohne JavaScript lesbar ist. Für jeden Fehler bekommst du einen Fix-Prompt zum Einfügen in den Lovable-Chat mit der exakten Änderung, und es kann täglich neu scannen, weil eine Code-Neugenerierung einen bereits behobenen Fehler zurückbringen kann.

Häufige Fragen

Hat Lovable das RLS-Problem schon behoben?

Lovable hat eine Sicherheitsprüfung vor dem Veröffentlichen ergänzt und die Templates verbessert, aber das Modell erzeugt weiterhin offene Policies, wenn eine Abfrage scheitert. RLS bleibt deine Verantwortung: Nutz die Abfragen aus dem Supabase-Guide.

Kann ich bei einer auf lovable.app gehosteten App Sicherheits-Header setzen?

Nicht aus Lovable heraus. Brauchst du sie, synchronisiere mit GitHub und deploye auf Vercel oder Netlify, wo sie per Datei konfiguriert werden. Die App wird weiterhin in Lovable bearbeitet.

Was tue ich, wenn ich einen geheimen Schlüssel in den Chat eingefügt habe?

Rotiere ihn beim Ursprungsdienst, auch wenn er nicht mehr im Code steht: Der Chat-Verlauf und frühere Bundles behalten ihn. Füg ihn danach über das Secrets-Feld hinzu und bitte das Modell, die Integration in eine Edge Function zu verschieben.