IST LOVABLE SICHER? EINE SICHERHEITSANALYSE

Ist Lovable sicher? Die kurze Antwort

Lovable als Plattform ist sicher. Mit Lovable gebaute Apps sind per Default nicht sicher. Die Plattform läuft auf Supabase, erzwingt HTTPS und patcht die eigene Infrastruktur. Die generierten Apps gehen mit einem vorhersagbaren Satz von Fehlern live, den der Entwickler meist nicht auditiert hat — fehlendes Row-Level-Security, offengelegte API-Keys und fehlende Owner-Checks in CRUD-Routen. Alles fixbar, aber du musst vorher scannen.

Die Fehlermuster sind in jeder Lovable-App, die wir analysiert haben, konsistent, was tatsächlich gute Nachricht ist: Du kannst die ganze Liste in einem Lauf prüfen.

Die drei Fehler, die am meisten zählen

1. Fehlendes Row-Level-Security in Supabase

Jede Lovable-App nutzt Supabase, und Supabase exponiert eine öffentliche REST-API für jede Tabelle. Ohne aktiviertes Row-Level-Security (RLS) und korrekte Policies gewährt diese API jedem, der die Supabase-URL kennt (die im JavaScript deiner App landet), vollen Lese- und Schreibzugriff auf die DB.

Was auf dem Spiel steht: Nutzer-E-Mails, Passwort-Hashes, personenbezogene Daten, Zahlungsdaten, private Nachrichten, interne Notizen. Alles in einer ungeschützten Tabelle kann anonym gelesen oder geändert werden.

Warum das immer wieder passiert: Lovables KI legt neue Tabellen an, wenn Features hinzukommen, ergänzt aber nicht konsistent auf jeder Tabelle RLS-Policies. Eine sicher startende App kann nach einem einzigen neuen Feature verwundbar werden.

Wie man es fixt: Aktiviere RLS in jeder Tabelle im Supabase-Dashboard und schreibe Policies, die zu deiner Auth-Logik passen. Siehe Supabase RLS Checker zur Validierung jeder Tabelle.

-- Minimal-Policy: Nutzer dürfen nur eigene Zeilen lesen
alter table projects enable row level security;

create policy "owner_can_read"
  on projects for select
  using (auth.uid() = owner_id);

create policy "owner_can_write"
  on projects for insert with check (auth.uid() = owner_id);

create policy "owner_can_update"
  on projects for update using (auth.uid() = owner_id);

create policy "owner_can_delete"
  on projects for delete using (auth.uid() = owner_id);

Häufiger Fehler: nur eine using-Klausel für select schreiben, dann den insert/update/delete-Pfad vergessen. Ohne with check kann ein Nutzer eine Zeile mit fremder owner_id einfügen und sie effektiv jemand anderem unterschieben.

2. Offengelegte API-Keys im Frontend-Bundle

Lovable-Apps betten oft API-Keys von Drittanbietern (Stripe, OpenAI, SendGrid, Analytics-Tools) direkt ins JavaScript-Bundle ein. Jeder, der DevTools öffnet, kann sie lesen. Credential-Harvesting-Bots finden sie innerhalb von Stunden nach dem Deploy.

Wie man es fixt: Verschiebe alle Keys, die nicht für den Client-Gebrauch gedacht sind — alles außer Supabase-Anon-Key, Stripe-Publishable-Key, Google-Maps-Key mit Referrer-Beschränkung und Ähnliches — hinter einen Backend-Proxy oder eine Supabase-Edge-Function. Nutze den Token Leak Checker, um offengelegte Keys zu finden.

Schnelle Selbstprüfung: Öffne die deployte App, drücke F12, gehe in den Sources-Tab und durchsuche das gebündelte JS nach sk_live_, sk_test_, xoxb-, eyJ, AKIA. Jeder Treffer ist mindestens ein Re-Key-Event, oft schlimmer.

// Anti-Muster: OpenAI-Key im Frontend
const openai = new OpenAI({
  apiKey: import.meta.env.VITE_OPENAI_KEY, // landet im Bundle, lesbar
})

// Korrekt: Edge Function als Proxy
const res = await fetch('/api/ask', { method: 'POST', body: prompt })

Die Edge Function hält den Key als Secret, fügt eine Auth-Prüfung gegen die Supabase-Session hinzu und kann Rate-Limiting pro Nutzer machen — drei Schutzschichten, die der Direktaufruf vom Browser nicht hat.

3. BOLA / IDOR in generierten CRUD-Routen

KI-generierte Ressourcen-Endpoints filtern typischerweise nach ID, überspringen aber den Check „Gehört diese ID diesem Nutzer?". Das heißt, eine Projekt-ID in der URL zu tauschen kann ein fremdes Projekt, Bankdaten oder private Infos offenlegen. Das ist das Broken-Object-Level-Authorization-Muster und die schadensträchtigste Bug-Klasse in produktiven Lovable-Apps.

Wie man es fixt: Jeder Endpoint, der eine Ressourcen-ID nimmt, muss prüfen, dass der authentifizierte Nutzer Eigentümer ist, bevor Daten zurückgegeben werden. In Supabase sieht das typischerweise so aus, dass eine RLS-Policy auth.uid() = owner_id prüft.

Test-Rezept, um BOLA in einer Lovable-App zu finden:

1. Logge dich mit User A ein, erstelle eine Ressource, kopiere die ID aus der URL.
2. Logge dich aus, logge dich mit User B ein.
3. Bau die URL mit User As ID nach. Antwortet die App mit den Daten — nicht mit 403/404 — ist BOLA bestätigt.
4. Wiederhole für PUT/DELETE-Endpoints. Der gefährlichste Fall ist ein Schreibendpoint, der fremde Ressourcen ändert.

Häufige Sicherheitsprobleme in Lovable-Apps

Offengelegte API-Keys

KI-Tools betten Keys direkt in JavaScript-Bundles ein. Sichtbar für jeden, der den Quellcode inspiziert, und binnen Minuten nach dem Deploy auch für Bots.

Fehlende RLS-Policies

Supabase-Apps gehen ohne Row-Level-Security live und erlauben unbefugten Lese-/Schreibzugriff auf Nutzerdaten.

Fehlender Owner-Check (BOLA)

Generierte CRUD-Endpoints filtern nach ID, überspringen aber den Authorization-Check, der sicherstellt, dass der Nutzer Eigentümer der Ressource ist.

Unzureichende Eingabevalidierung

KI-generierter Code nimmt oft an, dass Eingaben valide sind, und öffnet so Türen für SQL-Injection, XSS und Prompt-Injection.

Fehlende Security-Header

Content-Security-Policy, Strict-Transport-Security, X-Frame-Options und Referrer-Policy fehlen meist in KI-generierten Deployments.

Öffentliche Storage-Buckets

Supabase-Storage und Drittanbieter-Buckets gehen oft mit anonymem Lesezugriff live und leaken Uploads an die ganze Welt.

Service-Role-Key statt Anon-Key

Manche Lovable-Generationen platzieren den Supabase-service_role-Key im Frontend, weil ein Feature mit Anon-Key wegen RLS nicht funktionierte. Der service_role-Key umgeht RLS komplett. Das ist der Worst Case: jede Tabelle, jede Zeile, ohne Auth lesbar und schreibbar.

Fehlende Rate Limits auf Auth-Endpoints

Die Login- und Signup-Routen einer Lovable-App haben standardmäßig keinen Brute-Force-Schutz. Das öffnet die Tür für Credential Stuffing und Account-Enumeration. Konfiguriere Supabase-Rate-Limits in den Auth-Settings und ergänze CAPTCHA für die Public-Endpoints.

Häufige Fehler beim Lovable-Workflow

• Erste Tabelle perfekt absichern, Folge-Tabellen vergessen. Das nächste Feature legt eine neue Tabelle an, die ohne Policy live geht. Der Audit muss bei jedem Release wiederholt werden, nicht nur beim ersten Launch.
• Storage-Bucket „Public" lassen, weil das Bild-Upload sonst nicht klappt. Die richtige Antwort ist eine signierte URL pro Request, nicht ein offener Bucket.
• Die Lovable-Vorschau-URL für „Production" halten. Die Vorschau ist häufig ohne Auth-Schicht erreichbar. Vor dem echten Launch muss die Custom-Domain mit korrekter Site-URL in Supabase Auth gesetzt sein.
• Den Code-Editor-Tab in Lovable benutzen, um Secrets „kurz zu testen". Die Werte landen im Build und im verbundenen Repo. Nutze stattdessen die Supabase-Edge-Function-Secrets oder Vercel/Netlify-Env-Vars.

Pre-Launch-Checkliste für Lovable-Apps

1. RLS auf jeder Tabelle aktiv — verifiziere im Supabase-Dashboard unter Authentication → Policies, dass jede Tabelle mindestens eine Policy hat.
2. Frontend-Bundle nach Secrets durchsucht — npm run build, dann grep -r 'sk_\|sk-proj\|service_role' dist/ ausführen.
3. BOLA-Test mit zwei Test-Accounts — wie oben beschrieben, jede ID-basierte Route durchprobieren.
4. Storage-Buckets auf Private gesetzt — alles, was nicht explizit öffentlich sein soll.
5. Auth-Rate-Limits konfiguriert — Supabase → Authentication → Rate Limits.
6. Custom-Domain mit korrekter Site-URL in Supabase Auth eingetragen, damit Magic Links nicht auf die Lovable-Vorschau zeigen.
7. Branch Protection auf main im verbundenen GitHub-Repo, sodass jeder Commit über einen PR mit automatisiertem Scan muss.

Sicherheitsbewertung

Was Lovable gut macht

• Supabase-Integration bringt gemanagtes Postgres mit soliden Defaults
• Eingebaute Authentifizierung mit OAuth-Anbietern
• Automatisches HTTPS für jedes Deployment
• Regelmäßige Plattform-Security-Patches
• Vorhersagbare Fehlermuster machen das Scannen günstig

Was du selbst prüfen musst

• Row-Level-Security auf jeder Tabelle (der größte Hebel)
• Credential-Hygiene im Frontend-Bundle
• Autorisierung an jedem Endpoint, der eine Ressourcen-ID nimmt
• Eingabevalidierung in jedem Formular und API-Call
• Security-Header in der produktiven App
• Storage-Bucket-Policies und signierte URLs statt Public-Read
• Rate-Limits auf Auth- und API-Endpoints
• Kein service_role-Key im Browser-Bundle

Lovable für Enterprise

Lovable ist primär auf Solo-Builder und kleine Teams ausgerichtet. Wenn du es im Unternehmenskontext einsetzen willst:

• Eigenes Supabase-Projekt statt der Default-Lovable-Integration, damit dein Sicherheitsteam volle Kontrolle über Auth-Settings, Backups und Audit-Logs behält.
• Self-Hosted-Edge-Functions für jede Drittanbieter-API mit Server-Secrets, statt Keys im Frontend.
• CI-Gate im verbundenen GitHub-Repo, das vor jedem Deploy einen Security-Scan ausführt.
• DSGVO/AVV mit Lovable und Supabase abschließen, bevor produktive Personendaten verarbeitet werden.
• Backup-Strategie in Supabase aktivieren — Lovable übernimmt das nicht für dich.

Das Fazit

Lovable ist als Entwicklungsplattform sicher. Mit Lovable gebaute Apps brauchen vor dem Produktiv-Deploy ein Security-Review. Die drei Prüfungen, die zählen — RLS, Credentials, Autorisierung — sind mechanisch und scanbar. Führe sie vor jedem Launch durch, bei jedem Launch. Ein viraler Launch mit fehlendem RLS ist ein viraler Leak.

Verwandte Ressourcen

• Lovable Security Scanner — führe einen vollen Scan deiner Lovable-App durch
• Lovable-Security-Checkliste — Schritt-für-Schritt-Checkliste vor dem Launch
• Lovable-Security-Guide — Tiefgang zu häufigen Problemen
• Vibe-Coding-Sicherheitsrisiken — das übergreifende Fehlermuster von KI-Tools
• Token Leak Checker — gezielter Scan nach offengelegten API-Keys
• Supabase RLS Checker — prüft, ob jede Supabase-Tabelle eine korrekte Policy hat
• Vibe Code Scanner — breiter Scan über alle KI-App-Plattformen

Analysiere deine Lovable-App

Führe den kostenlosen VibeEval-Scanner gegen die URL deiner produktiven Lovable-App aus. Ergebnisse in unter 60 Sekunden.