WARUM JEDES LOVABLE-PROJEKT SECURITY-TESTING BRAUCHT

Das versteckte Risiko in der KI-Entwicklung

Versteh mich nicht falsch — Lovable ist beeindruckend. Du kannst in Stunden ganze Anwendungen bauen, die früher Wochen gedauert hätten. Aber eine Sache, über die niemand spricht: Wenn du mit dieser Geschwindigkeit unterwegs bist, fällt Security oft zurück.

Klassische Security-Tools wurden nicht für KI-generierten Code gebaut. Sie übersehen Muster und Schwachstellen, die entstehen, wenn eine KI einen Großteil deiner Anwendung schreibt. Darum haben wir den Lovable Security Scanner gebaut.

Was macht Lovable-Projekte anders?

KI-Coding-Assistenten wie Lovable haben die Art, Web-Apps zu bauen, revolutioniert. Aber sie bringen auch einzigartige Security-Überlegungen mit, die klassische Scanner nicht erfassen:

• Default-Schwachstellen: Die KI generiert manchmal Code-Muster, die perfekt funktionieren, aber subtile Security-Lücken enthalten
• Integrations-Blindspots: Wenn die KI verschiedene Services und APIs verbindet, können Security-Gaps zwischen den Komponenten entstehen
• Schnelle Iteration: Die Geschwindigkeit der KI-Entwicklung kann Security-Schulden schneller wachsen lassen, als manuelle Reviews sie fangen

Echte Probleme, die wir in Lovable-Projekten finden

Nach dem Scan vieler Lovable-Apps haben wir mehrere häufige Muster identifiziert, auf die Entwickler achten müssen:

Die 6 Vibe-Coding-Flows, die am häufigsten brechen

„Vibe Coding" — eine funktionierende App durch Gespräch mit einer KI herausbringen und nie die Hälfte des generierten Codes lesen — hat eine vorhersagbare Form. In 1.430+ Lovable-Scans verursachen dieselben sechs Flows die Mehrzahl der Criticals. Würdest du nur diese härten, eliminierst du den Großteil der produktionskritischen Bugs in KI-generierten Apps.

Jeder dieser Flows produziert in unseren Reports dasselbe Symptom: saubere UI, funktionierende App und ein Critical-Finding am Endpoint dahinter. Der Scanner geht alle sechs automatisch durch. Für mehr Kontext, warum diese Muster in KI-generiertem Code auftauchen, siehe Vibe Coding Security Checks und das RLS-Baseline-Beispiel der Beauty-Bloggerin.

RLS-Fehlkonfiguration: die Nr.-1-Schwachstelle

Nach dem Scan von 1.430+ Lovable-Anwendungen sticht eine Schwachstelle über allen heraus: fehlende oder falsch konfigurierte Row-Level-Security-(RLS)-Policies. Das Problem taucht weiter in neuen Lovable-Projekten auf.

Lovable nutzt Supabase als Datenbank. Supabase exponiert einen öffentlichen API-Endpoint, den jeder direkt aufrufen kann. Ohne RLS-Policies hält nichts einen Angreifer davon ab, jede Zeile deiner DB zu lesen, fremde Daten zu ändern oder Datensätze komplett zu löschen.

Die vier RLS-Checks, die jede Tabelle braucht

RLS ist kein einzelner Schalter. Es ist eine Policy pro Operation pro Tabelle. Eine übersehen und die Angriffsfläche bleibt sperrangelweit offen. Unser Scanner führt alle vier auf jeder gefundenen öffentlichen Tabelle aus:

Der häufige Fehler: Entwickler testen SELECT, sehen es ist gesperrt und gehen live. Writes bleiben offen. Wir sehen das in ~30 % der Apps, die „RLS aktiviert" haben.

Kaputte Policies, die richtig aussehen

Das sind die RLS-Policies, die wir am häufigsten flaggen — sie kompilieren, die App funktioniert, und die Tabelle ist weiterhin exponiert:

-- SCHLECHT: ohne WITH CHECK kann der Nutzer Zeilen beliebiger user INSERTen
CREATE POLICY "insert own" ON posts
  FOR INSERT USING (auth.uid() = user_id);

-- SCHLECHT: UPDATE nur mit USING; Nutzer aktualisiert eigene Zeile
-- und ändert gleichzeitig user_id auf die einer anderen Person
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id);

-- SCHLECHT: liest eigene + öffentlich markierte, ohne Column-Filter
-- — sensible Felder in „öffentlichen" Zeilen leaken
CREATE POLICY "read public or own" ON posts
  FOR SELECT USING (is_public OR auth.uid() = user_id);

-- SCHLECHT: der Klassiker „damit-es-läuft"-Fix
CREATE POLICY "allow all" ON posts FOR ALL USING (true);

Die korrigierten Versionen — die Muster, die unter Tests halten:

-- GUT: INSERT mit WITH CHECK bindet die neue Zeile an den Aufrufer
CREATE POLICY "insert own" ON posts
  FOR INSERT WITH CHECK (auth.uid() = user_id);

-- GUT: UPDATE verlangt, dass aktuelle Zeile dem Aufrufer gehört
-- UND dass die neue Version auch (verhindert Ownership-Transfer)
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id)
              WITH CHECK (auth.uid() = user_id);

-- GUT: DELETE auf Owner beschränkt
CREATE POLICY "delete own" ON posts
  FOR DELETE USING (auth.uid() = user_id);

-- GUT: SELECT explizit, keine Ambiguität
CREATE POLICY "read own" ON posts
  FOR SELECT USING (auth.uid() = user_id);

Für Spalten mit PII (E-Mail, Telefon, stripe_customer_id) nutze lieber eine View mit beschränkten Spalten statt Column-Level-Grants — einfacher zu konfigurieren und zu auditieren.

Teste dein RLS in 30 Sekunden

Du brauchst unseren Scanner nicht für einen ersten Durchlauf. Öffne deine produktive Lovable-App, hol die Supabase-URL und den Anon-Key aus dem Network-Tab und fahr:

# Ersetze mit deinem Projekt + Anon-Key + Tabelle
SUPA="https://<project>.supabase.co"
KEY="<anon_key>"
TABLE="profiles"

# Read-Probe — sollte leer oder 401 ohne Login sein
curl "$SUPA/rest/v1/$TABLE?select=*&limit=5" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY"

# Write-Probe — sollte 401 oder Policy-Rejection sein
curl -X POST "$SUPA/rest/v1/$TABLE" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"id":"rls-probe-delete-me"}'

Kommen Zeilen zurück oder der Write geht durch, hast du ein Critical. Führe den kostenlosen Supabase RLS Checker für den vollen Per-Tabellen-Report aus oder füge die URL oben in den Scanner ein für das volle Lovable-Audit (Auth, Storage, Edge Functions und Keys, nicht nur RLS).

Wenn RLS nicht reicht

RLS stoppt den Anon-Key. Es stoppt nicht:

• Edge Functions mit Service-Role-Key — die ignorieren RLS komplett. Jeder Logikfehler in einer Funktion ist volles Lesen/Schreiben auf der DB.
• Geleakte JWTs — leakt das JWT eines eingeloggten Nutzers (XSS, öffentlicher Gist, Screenshot), serviert RLS dem Angreifer fröhlich, was dieser Nutzer sähe.
• Storage — Storage hat RLS-ähnliche Regeln pro Bucket und pro Objekt. Sie werden separat konfiguriert und in Lovable-Apps oft als „public bucket" belassen.
• Views und DB-Funktionen — eine SECURITY DEFINER-Funktion läuft mit den Rechten des Erstellers, nicht des Aufrufers. Nimmt sie eine vom Nutzer gelieferte ID und vertraut ihr, ist RLS irrelevant.

Unser Scanner testet alle vier. Zum Verständnis des Policy-Modells siehe den Supabase-RLS-Guide und die Supabase-Security-Checkliste.

Wie der Lovable Security Scanner funktioniert

Unser Scanner versteht speziell die Architektur von Lovable. Das passiert, wenn du dein Projekt scannst:

1. Automatische Discovery: Wir crawlen deine Anwendung, um Struktur, Routen und Funktionalität zu verstehen
2. KI-gestützte Tests: 13 spezialisierte KI-Agents testen Angriffsszenarien speziell für Web-Anwendungen
3. Schwachstellen-Erkennung: Wir identifizieren Security-Probleme, von Basis-Fehlkonfigurationen bis komplexen Auth-Bypasses
4. Umsetzbare Reports: Klare Erklärungen der Probleme und spezifische Fix-Schritte

Jenseits des Scans: vollständige Security-Abdeckung

Der Lovable Security Scanner geht nicht nur ums Finden von Schwachstellen. Er ist eine komplette Security-Lösung:

• Multi-Browser-Tests: stellt sicher, dass deine App in verschiedenen Browsern sicher funktioniert
• Supabase-RLS-Verifikation: End-to-End-Test deiner Row-Level-Security-Policies
• Tägliches Monitoring: kontinuierlicher Scan, um neue Probleme zu fangen, wenn deine App wächst
• Data-Leak-Prävention: erkennt sensible Informationen, die exponiert sein könnten
• API-Token-Schutz: verhindert versehentliches Offenlegen sensibler Credentials
• Launch-Readiness-Checks: umfassende Security-Validierung vor dem Deploy

Was Entwickler finden

Unter den 5.711 Schwachstellen, die in 1.430+ gescannten Apps gefunden wurden, ist dies das Ranking der häufigsten Probleme:

1. Fehlendes RLS auf SELECT — Kritisch. Präsent in 85 % der Scans.
2. Fehlendes RLS auf INSERT/UPDATE/DELETE — Kritisch. Präsent in 51 % der Scans. Geht meist zusammen mit einer funktionierenden SELECT-Policy live, und rutscht deshalb durch.
3. Offengelegte API-Keys — Kritisch. Präsent in 62 % der Scans. OpenAI, Anthropic, Stripe und Resend sind die vier am häufigsten geleakten.
4. Auth-Bypasses — Hoch. Präsent in 45 % der Scans. Meist ein reiner Frontend-Route-Guard.
5. Fehlende Eingabevalidierung — Hoch. Präsent in 38 % der Scans.
6. Öffentlicher Storage-Bucket — Hoch. Präsent in 34 % der Lovable-Apps, die Storage nutzen.
7. Bezahl-Feature-Gates nur im Frontend — Hoch. Präsent in 27 % der monetarisierten Apps.
8. Service-Role-Key im Client-Code — Kritisch. Selten (~4 %), aber immer vollständiger Takeover.

Der Einstieg ist simpel

Du musst kein Security-Experte sein, um deine Lovable-Projekte abzusichern. Füge oben die URL deiner produktiven App ein. In Minuten bekommst du einen umfassenden Security-Report mit umsetzbaren Empfehlungen.

Starte mit 14 Tagen kostenlosem Test. Kein langes Setup. Nur echte Security-Insights für echte Anwendungen.