Lovable-generierte Codebasis-Audits: Sicherheitsprobleme, RLS-Lücken und offengelegte API-Schlüssel

Ein Kunde kam letzten Monat mit einer Lovable-generierten App zu uns, die bereits in der Produktion mit zahlenden Kunden live war. Sie wollten, dass wir ein paar Features hinzufügen und "ein bisschen aufräumen." Was wir bei unserem anfänglichen Codebase-Audit fanden, war... aufschlussreich. Offengelegte API-Schlüssel in Client-seitigen Code. Fehlende Row Level Security-Richtlinien für Tabellen mit Benutzerdaten. Direkte Supabase-Aufrufe ohne serverseitige Validierung. Und das war kein Einzelfall -- wir haben mittlerweile sechs verschiedene Lovable-Projekte auditiert, und die Muster sind bemerkenswert konsistent.

Lassen Sie mich das klarmachen: Lovable ist ein beeindruckendes Tool zum Prototyping. Die Geschwindigkeit, mit der es funktionierende UI aus natürlichsprachigen Prompts generiert, ist wirklich bemerkenswert. Aber es gibt eine massive Lücke zwischen "funktionierendem Prototyp" und "produktionsreifer Anwendung", und diese Lücke ist mit Sicherheitslücken gefüllt, nach denen die meisten nicht-technischen Gründer nicht einmal suchen.

Dieser Artikel ist eine technische Analyse dessen, was wir über mehrere Lovable-Codebase-Audits hinweg gefunden haben. Wenn Sie etwas mit Lovable erstellt haben und echte Benutzerdaten oder -geld annehmen, müssen Sie dies lesen.

Inhaltsverzeichnis

Lovable Codebase Audit: Security Issues, RLS Gaps, and Exposed API Keys

Was Lovable wirklich generiert

Lovable generiert React-Anwendungen (typischerweise mit Vite) mit Tailwind CSS und shadcn/ui-Komponenten, verbunden mit einem Supabase-Backend. Der Stack selbst ist solide -- wir bauen mit diesen gleichen Tools regelmäßig in unserer Next.js-Entwicklung auf. Das Problem ist nicht die Technologieauswahl. Es ist, wie sie zusammengefügt werden.

Hier ist eine typische Lovable-Projektstruktur:

src/
├── components/
│   ├── ui/           # shadcn Komponenten
│   ├── Dashboard.tsx
│   ├── Settings.tsx
│   └── ...
├── integrations/
│   └── supabase/
│       ├── client.ts  # ← Hier fangen die Probleme an
│       └── types.ts
├── pages/
├── hooks/
└── lib/

Der generierte Code ist sauber und lesbar. Ich gebe Lovable dafür Anerkennung. Aber Lesbarkeit ist nicht gleich Sicherheit. Die Architektur trifft Entscheidungen, die für eine Demo in Ordnung sind, aber für die Produktion gefährlich sind.

Lassen Sie uns konkret werden.

Das API-Schlüssel-Problem

Jedes Lovable-Projekt, das wir auditiert haben, hat Supabase-Anmeldedaten im Client-seitigen Code. Nun, bevor die Supabase-Verteidiger auftauchen: ja, der anon-Schlüssel ist entworfen, um öffentlich zu sein. Die Supabase-Dokumentation besagt dies explizit. Der anon-Schlüssel ist für die Verwendung in Client-seitigen Code gedacht, und die Sicherheit soll durch Row Level Security-Richtlinien durchgesetzt werden.

Aber hier wird es hässlich.

In drei der sechs Projekte, die wir auditiert haben, fanden wir den Supabase service_role-Schlüssel entweder:

  1. Direkt in einer Utility-Datei hardcodiert
  2. In einer .env-Datei gespeichert, die zum GitHub-Repo committed wurde
  3. In einer Supabase Edge Function referenziert, die ohne Authentifizierung zugänglich war

Der service_role-Schlüssel umgeht alle RLS-Richtlinien. Wenn jemand ihn bekommt, hat er vollständigen Lese-/Schreibzugriff auf Ihre gesamte Datenbank. Jede Tabelle. Jede Zeile. Die Daten jedes Benutzers.

// Tatsächliches Muster, das wir in einem Lovable-Projekt gefunden haben (Schlüssel unkenntlich gemacht)
import { createClient } from '@supabase/supabase-js'

// Dies war in einer Datei namens lib/admin.ts
// importiert und in einer Client-seitigen Komponente verwendet
const supabaseAdmin = createClient(
  'https://xxxxx.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // service_role Schlüssel!
)

Dies wurde nicht direkt von Lovable generiert -- es wurde vom Gründer hinzugefügt, als er Admin-Funktionen brauchte und Lovable fragte, um "ein Admin-Panel hinzuzufügen." Lovable stimmte zu, und da es kein Konzept der Sicherheitsgrenzen zwischen Server und Client hat, platzierte es den Schlüssel, wo er bequem war.

Selbst wenn nur der anon-Schlüssel offengelegt wird (wie beabsichtigt), fällt das Sicherheitsmodell auseinander, wenn RLS nicht richtig konfiguriert ist. Was uns zur großen Sache bringt.

Row Level Security: Der stille Killer

Row Level Security (RLS) ist Supabase's primärer Sicherheitsmechanismus zum Schutz von Daten auf Datenbankebene. Wenn korrekt konfiguriert, stellt es sicher, dass Benutzer unabhängig von den gemachten API-Aufrufen vom Client nur auf ihre eigenen Daten zugreifen können.

Als wir die sechs Lovable-Projekte auditiert haben, fanden wir folgendes:

Projekt Tabellen Gesamt Tabellen mit RLS aktiviert Tabellen mit korrekten RLS-Richtlinien Sensible Daten offengelegt
SaaS-Dashboard 14 6 3 Benutzer-PII, Abrechnungsdaten
E-Commerce-App 22 10 4 Bestellverlauf, Adressen
Gesundheitstracker 11 4 2 Gesundheitsunterlagen, Medikationen
Projekt-Manager 18 8 5 Kundendaten, Dokumente
Buchungsplattform 16 7 3 Kontaktinformationen, Zeitpläne
CRM-Tool 20 9 4 Kundendaten, Notizen

Lesen Sie das nochmal. In der Gesundheitstracker-App -- die tatsächliche Medikamenten- und Gesundheitsinformationen speicherte -- hatten nur 2 von 11 Tabellen korrekte RLS-Richtlinien. Jemand mit dem anon-Schlüssel (der öffentlich ist, denken Sie daran) könnte die Gesundheitsunterlagen jedes Benutzers abfragen.

Die häufigsten RLS-Fehler, die wir sehen:

Fehlende Richtlinien völlig

Lovable erstellt oft Tabellen, ohne RLS überhaupt zu aktivieren. In Supabase ist RLS auf neuen Tabellen standardmäßig deaktiviert, was bedeutet, dass jeder mit dem anon-Schlüssel alle Daten lesen kann.

-- Was wir oft finden: RLS ist nicht einmal aktiviert
CREATE TABLE public.user_profiles (
  id UUID REFERENCES auth.users,
  full_name TEXT,
  email TEXT,
  phone TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Kein ALTER TABLE ... ENABLE ROW LEVEL SECURITY;
-- Keine Richtlinien definiert

Zu permissive Richtlinien

Wenn Lovable RLS hinzufügt, sind die Richtlinien oft zu breit:

-- Häufig generierte Lovable-Richtlinie
CREATE POLICY "Benutzer können alle Profile anzeigen"
  ON public.user_profiles
  FOR SELECT
  USING (true);  -- Dies erlaubt JEDEM authentifizierten Benutzer, ALLE Profile zu lesen

Die Korrektur sollte sein:

-- Wie es aussehen sollte
CREATE POLICY "Benutzer können eigenes Profil anzeigen"
  ON public.user_profiles
  FOR SELECT
  USING (auth.uid() = id);

Fehlende DELETE- und UPDATE-Richtlinien

Selbst wenn SELECT-Richtlinien korrekt sind, fehlen INSERT/UPDATE/DELETE-Richtlinien häufig oder sind falsch. Wir fanden Fälle, in denen jeder authentifizierte Benutzer das Profil eines anderen Benutzers aktualisieren konnte.

Lovable Codebase Audit: Security Issues, RLS Gaps, and Exposed API Keys - architecture

Authentifizierungs- und Autorisierungslücken

Lovable verwaltet die grundlegende Authentifizierung angemessen -- es richtet Supabase Auth mit Email/Passwort oder sozialen Logins ein, und die Login-/Anmelde-Flows funktionieren im Allgemeinen. Aber Authentifizierung (wer bist du?) und Autorisierung (was darfst du tun?) sind verschiedene Dinge.

Die Autorisierungsschicht ist fast immer unvollständig oder nicht vorhanden.

Betrachten Sie eine Multi-Tenant-SaaS-App. Benutzer gehören zu Organisationen. Sie sollten nur Daten aus ihrer Organisation sehen. Sie könnten verschiedene Rollen haben (Admin, Mitglied, Betrachter). Lovable generiert nichts davon.

Was wir typischerweise finden:

// Lovable-generierter Datenabruf
const { data: projects } = await supabase
  .from('projects')
  .select('*')
  // Kein Filter für organization_id
  // Keine Überprüfung der Rolle oder Berechtigungen des Benutzers

Die Korrektur erfordert sowohl Datenbank-Ebene (RLS) als auch Anwendungs-Ebene-Änderungen. Sie benötigen eine memberships-Tabelle, die Benutzer auf Organisationen mit Rollen abbildet, RLS-Richtlinien, die Mitgliedschaft überprüfen, und Anwendungscode, der angemessen filtert.

Dies ist die Art von Architektur-Arbeit, die schwer hinzuzufügen ist, nachdem die Tatsachen geschaffen wurden. Sie berührt jede Abfrage, jede Komponente, jede Seite. Wenn Sie eine Multi-Tenant-SaaS mit Lovable erstellen, ist dies das Ding, das Sie am härtesten treffen wird.

Offenlegung von Client-seitiger Geschäftslogik

Weil Lovable reine Client-seitige React-Apps generiert, lebt alle Geschäftslogik im Browser. Das bedeutet:

  • Preisberechnungen sind sichtbar und manipulierbar in Browser DevTools
  • Feature-Flags für verschiedene Abonnementstiers werden Client-seitig überprüft
  • Rabattcodes und Validierungslogik sind im JavaScript-Bundle
  • API-Ratenlimitierung existiert nicht (es gibt keinen Server, um sie durchzusetzen)

Wir fanden eine Lovable-generierte SaaS, bei der die Abonnementstier-Überprüfung völlig Client-seitig war:

// Gefunden in einer Komponente eines Lovable-Projekts
const canAccessFeature = (feature: string) => {
  const plan = user?.subscription?.plan
  if (plan === 'pro') return true
  if (plan === 'basic' && BASIC_FEATURES.includes(feature)) return true
  return false
}

Ein Benutzer könnte diese Funktion einfach in der Browserkonsole ändern -- oder die Supabase API direkt ohne diese Überprüfung aufrufen -- und auf Pro-Features mit einem Basic-Plan zugreifen. Die Datenbank hatte keine Richtlinien, die planbasierte Zugriffe durchsetzen.

Dies ist ein grundlegendes Architektur-Problem. Geschäftslogik benötigt eine Server-seitige Komponente. Ob das Next.js API-Routen, Supabase Edge Functions oder ein separater Backend-Service sind -- etwas muss Operationen überprüfen, wo der Benutzer es nicht manipulieren kann.

Dies ist genau der Grund, warum wir oft Frameworks wie Next.js oder Astro für produktive SaaS-Anwendungen empfehlen -- sie geben Ihnen Server-seitiges Rendering und API-Routen aus der Box.

Supabase Edge Functions: Was fehlt

Einige Lovable-Projekte nutzen Supabase Edge Functions für bestimmte Operationen -- typischerweise Stripe Webhook-Behandlung oder Email-Versand. Aber die Implementierung hat oft Probleme:

  1. Keine Eingabevalidierung: Edge Functions akzeptieren und verarbeiten alle JSON-Daten ohne Validierung von Form, Typen oder Beschränkungen.

  2. CORS konfiguriert, um alle Origins zu erlauben:

// Häufiges Muster in Lovable Edge Functions
const corsHeaders = {
  'Access-Control-Allow-Origin': '*',  // Erlaubt jeder Website, dies aufzurufen
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}

  1. Keine Authentifizierungsüberprüfung: Die Funktion überprüft nicht das JWT-Token, also können nicht authentifizierte Benutzer sie aufrufen.

  2. Stripe-Webhook-Signaturen nicht überprüft: In zwei Projekten überprüfte der Stripe-Webhook-Handler nicht die Webhook-Signatur, was bedeutet, dass jeder gefälschte Zahlungsereignisse zum Endpunkt senden konnte.

// Was wir fanden -- keine Signaturüberprüfung
Deno.serve(async (req) => {
  const body = await req.json()
  // Verarbeitet das Ereignis direkt, ohne zu überprüfen, dass es von Stripe kam
  if (body.type === 'checkout.session.completed') {
    // Aktualisieren Sie das Abonnement des Benutzers
    await supabaseAdmin.from('subscriptions').update({
      status: 'active',
      plan: 'pro'
    }).eq('user_id', body.data.object.metadata.user_id)
  }
})

Das bedeutet, ein Angreifer könnte eine POST-Anfrage an die Webhook-URL mit einem gefälschten checkout.session.completed-Ereignis senden und jeden Benutzer kostenlos auf einen Pro-Plan aktualisieren.

Häufige Schwachstellenmuster, die wir gefunden haben

Hier ist eine Zusammenfassung der häufigsten Probleme geordnet nach Schweregrad und Häufigkeit:

Sicherheitslücke Schweregrad Häufigkeit (von 6) Ausnutzbarkeit
Fehlende RLS bei sensiblen Tabellen Kritisch 6/6 Einfach -- fragen Sie einfach die Tabelle ab
Zu permissive RLS-Richtlinien Hoch 6/6 Einfach mit anon-Schlüssel
Service Role Key Offenlegung Kritisch 3/6 Trivial wenn gefunden
Keine Stripe Webhook-Überprüfung Hoch 4/6 Mittel -- Endpunkt-URL benötigt
Nur Client-seitige Autorisierung Hoch 6/6 Einfach mit DevTools
Keine Eingabevalidierung auf Edge Functions Mittel 5/6 Mittel
CORS-Wildcard auf Edge Functions Mittel 5/6 Einfach
Sensible Daten in localStorage Mittel 4/6 Physischer Zugriff oder XSS
Keine Ratenlimitierung Mittel 6/6 Trivial
Unsichere direkte Objektreferenzen Hoch 5/6 Einfach -- ändern Sie die ID in der URL

So überprüfen Sie Ihr eigenes Lovable-Projekt

Wenn Sie etwas mit Lovable erstellt haben, das echte Benutzerdaten verwaltet, so können Sie auf diese Probleme überprüfen.

Schritt 1: Überprüfen Sie Ihren Supabase RLS-Status

Gehen Sie zu Ihrem Supabase-Dashboard → Table Editor. Klicken Sie auf jede Tabelle und überprüfen Sie, ob RLS aktiviert ist. Gehen Sie dann zu Authentication → Policies und überprüfen Sie jede Richtlinie.

Oder führen Sie diese Abfrage im SQL Editor aus:

SELECT
  schemaname,
  tablename,
  rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY tablename;

Wenn rowsecurity für eine Tabelle mit Benutzerdaten false ist, das ist ein kritisches Problem.

Schritt 2: Suchen Sie nach offengelegten Schlüsseln

In Ihrer Codebasis, suchen Sie nach:

grep -r "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" src/
grep -r "service_role" src/
grep -r "SUPABASE_SERVICE" src/

Das erste Muster passt auf den Anfang von Supabase JWT-Schlüsseln. Wenn Sie den service_role-Schlüssel irgendwo in Ihrem src/-Verzeichnis finden, das ist eine unmittelbare kritische Sicherheitslücke.

Schritt 3: Testen Sie RLS-Richtlinien

Erstellen Sie ein zweites Test-Benutzerkonto. Melden Sie sich als dieser Benutzer an und versuchen Sie, auf Daten von Benutzer eins zuzugreifen. Überprüfen Sie die Registerkarte Network des Browsers -- erhalten Sie Daten, die Sie nicht bekommen sollten?

Sie können auch direkt mit curl testen:

curl 'https://YOUR_PROJECT.supabase.co/rest/v1/user_profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

Wenn dies alle Benutzerprofile ohne Authentifizierung zurückgibt, ist RLS unterbrochen.

Schritt 4: Überprüfen Sie Edge Functions

Überprüfen Sie jede Edge Function auf:

  • JWT-Überprüfung
  • Eingabevalidierung
  • CORS-Konfiguration
  • Webhook-Signaturüberprüfung (für Stripe/Zahlungs-Handler)

Schritt 5: Inspizieren Sie das Client-seitige Bundle

Führen Sie npm run build aus und inspizieren Sie die Ausgabe. Suchen Sie das gebaute JavaScript nach API-Schlüsseln, Geschäftslogik und Preisdaten. Alles im Bundle ist für Benutzer sichtbar.

Wann neu erstellen vs. Wann beheben

Das ist die Frage, mit der sich jeder Lovable-Gründer konfrontiert sieht, sobald er sich dieser Probleme bewusst wird. Die Antwort hängt von mehreren Faktoren ab:

Beheben Sie, wenn:

  • Ihre App weniger als 10 Tabellen hat
  • Sie kein komplexes Autorisierungsmodell haben (keine Multi-Tenancy, keine Rollen)
  • Die Kernarchitektur (Datenmodell, Seitenstruktur) solide ist
  • Sie hauptsächlich RLS-Richtlinien hinzufügen und einige Logik Server-seitig verschieben müssen

Erstellen Sie neu, wenn:

  • Sie eine Multi-Tenant-Architektur mit Rollen und Berechtigungen benötigen
  • Ihre Geschäftslogik ist komplex und völlig Client-seitig
  • Sie Server-seitiges Rendering für SEO oder Performance benötigen
  • Das Supabase-Schema hat bedeutende strukturelle Probleme
  • Sie in einem Umfang arbeiten, bei dem Sie eine angemessene Infrastruktur benötigen

Für Behebung suchen Sie typischerweise nach dem Hinzufügen von RLS-Richtlinien über alle Tabellen, dem Migrieren von sensiblen Logik zu Edge Functions oder einer Server-seitigen Schicht, dem Implementieren einer angemessenen Eingabevalidierung und dem Hinzufügen von Ratenlimitierung. Das ist ein 2-4 Wochen Projekt für einen erfahrenen Entwickler, abhängig von Komplexität.

Für einen vollständigen Neubau empfehlen wir typischerweise eine Headless-Architektur mit angemessener Trennung der Bedenken. Das kostet mehr upfront, aber gibt Ihnen eine Grundlage, die skaliert. Überprüfen Sie unsere Preisseite für ein Gefühl dafür, wie das aussieht.

Wenn Sie unsicher sind, welcher Weg der richtige ist, machen wir gerne eine schnelle Bewertung. Kontaktieren Sie uns auf unserer Kontaktseite.

FAQ

Ist es sicher, Lovable für produktive Anwendungen zu nutzen? Lovable kann einen soliden Ausgangspunkt generieren, aber die Ausgabe benötigt erhebliche Sicherheitshärtung, bevor sie produktionsreif ist. Der generierte Code mangelt ordnungsgemäße RLS-Richtlinien, Server-seitige Validierung und Autorisierungslogik. Denken Sie daran als Gerüst, nicht als das fertige Gebäude. Sie benötigen absolut einen Entwickler, um den Code zu überprüfen und zu sichern, bevor echte Benutzer ihm ihre Daten anvertrauen.

Legt Lovable meine Supabase API-Schlüssel offen? Der Supabase anon-Schlüssel ist absichtlich öffentlich -- das ist das Design, und Supabase's Sicherheitsmodell berücksichtigt es durch RLS. Das Problem tritt auf, wenn Lovable (oder Sie, durch Prompts) den service_role-Schlüssel in Client-seitigen Code legt. Der anon-Schlüssel, der öffentlich ist, ist nur sicher, wenn Ihre RLS-Richtlinien wasserdicht sind, was bei Lovable-generierten Projekten normalerweise nicht der Fall ist.

Was ist Row Level Security und warum ist es wichtig? Row Level Security (RLS) ist eine PostgreSQL-Funktion, die Supabase nutzt, um zu steuern, welche Zeilen ein Benutzer lesen, einfügen, aktualisieren oder löschen kann. Ohne RLS kann jeder mit Ihrem öffentlichen anon-Schlüssel Ihre gesamte Datenbank abfragen -- jedes Benutzer's Daten, jeder private Datensatz. Es ist der single most wichtigste Sicherheitsmechanismus in einer Supabase-gestützten Anwendung, und es ist das single most häufig falsch konfigurierte Ding in Lovable-Projekten.

Kann ich Lovable-Sicherheitsprobleme selbst ohne einen Entwickler beheben? Wenn Sie SQL und Supabase's RLS-Richtliniensyntax verstehen, können Sie grundlegende RLS-Richtlinien selbst hinzufügen, indem Sie das Supabase-Dashboard nutzen. Die Richtlinien richtig zu bekommen -- besonders für komplexe Szenarien wie Multi-Tenancy, gemeinsame Ressourcen oder Admin-Zugriff -- erfordert Erfahrung. Eine falsche Richtlinie kann entweder Benutzer aus ihren eigenen Daten sperren oder alles offen lassen. Für etwas über ein einfaches persönliches Projekt hinaus, lassen Sie professionelle Augen darauf sehen.

Wie überprüfe ich, ob meine Lovable-App's Datenbank sicher ist? Der schnellste Test: Öffnen Sie Ihre Browserkonsolen DevTools, gehen Sie zur Network-Registerkarte, und schauen Sie sich die Supabase API-Aufrufe an, die Ihre App macht. Kopieren Sie den apikey Header-Wert. Dann nutzen Sie curl oder Postman, um Ihre Tabellen direkt abzufragen, indem Sie nur diesen Schlüssel mit keinem Auth-Token nutzen. Wenn Sie andere Benutzer's Daten bekommen -- oder irgendwelche Daten überhaupt bei Tabellen, die privat sein sollten -- Ihre RLS ist unterbrochen.

Welche sind die größten Sicherheitsrisiken mit KI-generiertem Code im Allgemeinen? KI-Code-Generatoren optimieren dafür, Dinge zum Laufen zu bringen, nicht für Sicherheit. Sie haben kein mentales Modell Ihrer Bedrohungslandschaft. Die größten Risiken sind: offengelegte Geheimnisse, fehlende Eingabevalidierung, overly permissive Zugriffskontrolle und die Abwesenheit von Server-seitigen Sicherheitsgrenzen. Diese sind nicht einzigartig für Lovable -- ähnliche Probleme existieren im Code von Cursor, v0, Bolt und anderen KI-Tools. Der Unterschied ist, dass Lovable vollständige Anwendungen generiert, die Leute direkt zur Produktion deployed.

Sollte ich nach der Nutzung von Lovable von Supabase zu einem anderen Backend wechseln? Supabase selbst ist in Ordnung. Es ist eine solide Plattform mit ordnungsgemäßen Sicherheits-Fähigkeiten. Das Problem ist, wie Lovable es konfiguriert. Sie müssen nicht Supabase aufgeben -- Sie müssen ordnungsgemäß RLS-Richtlinien konfigurieren, sensible Operationen zu Edge Functions migrieren und die Autorisierungsschicht hinzufügen, die Lovable übersprungen hat. Die Infrastruktur ist gut; die Konfiguration benötigt einfach Arbeit.

Wie viel kostet es, Sicherheitsprobleme in einer Lovable-generierten App zu beheben? Für eine einfache Behebung -- RLS-Richtlinien hinzufügen, Edge Functions sichern, offengelegte Schlüssel entfernen, grundlegende Eingabevalidierung hinzufügen -- suchen Sie nach ungefähr $3,000-$8,000 abhängig von der Anzahl der Tabellen und Komplexität Ihres Autorisierungsmodells. Ein vollständiger Neubau mit ordnungsgemäßer Architektur kostet $15,000-$50,000+ abhängig von Umfang. Der Behebungs-Weg ist fast immer kostengünstiger, wenn Ihr Kern-Datenmodell solide ist.