Mit Lovable, Bolt oder Replit gebaut: diese Punkte sind wahrscheinlich offen

01

Was leisten Lovable, Bolt und Replit, und wo hört das auf?

Die Werkzeuge erzeugen aus Beschreibungen in natürlicher Sprache lauffähige Webanwendungen und nehmen Einrichtung, Hosting und oft die Datenbank ab. Für Prototypen und interne Experimente ist das ein echter Gewinn. Offen bleibt, was kein Prompt verlangt hat: Zugriffsregeln, Schlüsselverwaltung, Schemaversionen, Protokollierung und ein Weg aus der Plattform.

Lovable erzeugt laut Dokumentation Standardprojekte mit Vite und React und stützt sich im Backend auf Supabase für Datenbank, Anmeldung, Speicher und serverseitige Funktionen. Bolt-Projekte lassen sich als ZIP herunterladen, Replit ist eine Entwicklungsumgebung im Browser. Keiner der folgenden Punkte ist ein Fehler nur dieser Werkzeuge, dieselben Lücken entstehen in handgeschriebenem Code, nur langsamer.

Eine Vorschau beantwortet, ob die Idee funktioniert, nicht aber, ob die Anwendung echte Kundendaten, mehrere Rollen und Zugriffe von außen verträgt. Welche Fragen ein Produktivsystem zusätzlich stellt, ordnet der Leitfaden Vom Prototyp zur produktionsreifen Anwendung ein. Hier geht es um die Mechanismen, die Sie zuerst prüfen sollten.

02

Was ist Row Level Security, und warum entscheidet die Voreinstellung?

Row Level Security (RLS) ist eine PostgreSQL-Funktion, die zeilenweise festlegt, wer welche Daten lesen oder ändern darf. Spricht der Browser-Code direkt mit der Supabase-Datenbank, ist RLS die eigentliche Zugriffskontrolle. Fehlt RLS auf einer Tabelle im öffentlichen Schema, kann laut Supabase jeder mit der Projektadresse dort lesen, ändern und löschen.

In vielen generierten Anwendungen gibt es keinen eigenen Server, der Anfragen prüft: Der Browser ruft die Datenbank-API von Supabase direkt auf und schickt einen öffentlichen Schlüssel mit. Supabase nennt diesen Publishable Key (früher anon) unbedenklich im Frontend, aber nur, weil die Datenbank selbst entscheidet, welche Zeilen die Rollen anon und authenticated sehen. Grants regeln, ob eine Rolle eine Operation ausführen darf, Policies, welche Zeilen davon betroffen sind.

Die Voreinstellung hängt davon ab, wie die Tabelle entstand

Über das Supabase-Dashboard angelegte Tabellen haben RLS standardmäßig aktiv. Im SQL-Editor oder von anderen Werkzeugen erzeugte Tabellen bekommen RLS erst, wenn es jemand einschaltet, und genau so arbeiten KI-Assistenten, wenn sie Schemaänderungen als SQL ausführen. RLS ohne Policy liefert über die API keine Daten mehr: Das wirkt wie ein Fehler, ist aber der sichere Zustand.

-- RLS für die Tabelle einschalten
alter table public.bestellungen enable row level security;

-- Angemeldete Nutzer lesen nur ihre eigenen Bestellungen
create policy "Eigene Bestellungen lesen"
on public.bestellungen for select to authenticated
using ( (select auth.uid()) = user_id );

-- Neue Zeilen nur im eigenen Namen anlegen
create policy "Eigene Bestellungen anlegen"
on public.bestellungen for insert to authenticated
with check ( (select auth.uid()) = user_id );

03

Wie prüfen Sie RLS in Ihrem Projekt selbst?

Am schnellsten über den Security Advisor im Supabase-Dashboard, der Tabellen ohne RLS und zu offene Policies meldet. Danach helfen zwei SQL-Abfragen und ein Test von außen: Kommen mit dem öffentlichen Schlüssel und ohne Anmeldung Zeilen zurück, die niemand Fremdes sehen dürfte, ist die Tabelle offen.

1. Security Advisor starten

   Im Dashboard oder mit supabase db advisors. Relevant sind vor allem rls_disabled_in_public, policy_exists_rls_disabled und permissive_rls_policy.

2. Kataloge abfragen

   Die SQL-Abfragen unten zeigen RLS-Status und Policies. Jede Tabelle mit rowsecurity = false braucht eine Begründung, jede Policy eine fachliche Regel.

3. Von außen testen

   Eine Tabelle mit dem öffentlichen Schlüssel ohne Anmeldung abrufen, nur im eigenen Projekt. [] heißt: wirksames RLS oder leere Tabelle.

4. Quer testen

   Mit zwei Testkonten versuchen, fremde Datensätze zu lesen oder zu ändern. Erst das zeigt, ob die Policies die Geschäftsregel abbilden.

-- Welche Tabellen im Schema public haben kein RLS?
select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

-- Welche Policies gibt es, für welche Rollen und Operationen?
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename, policyname;

# Nur gegen Ihr eigenes Projekt ausführen
curl 'https://<PROJECT_REF>.supabase.co/rest/v1/<tabelle>?select=*' \
  -H "apikey: <PUBLISHABLE_KEY>"

04

Was ist bei CVE-2025-48757 passiert?

Der NVD-Eintrag beschreibt unzureichende Row-Level-Security-Richtlinien in Lovable bis zum 15. April 2025, durch die nicht angemeldete Angreifer aus der Ferne beliebige Datenbanktabellen generierter Seiten lesen und beschreiben konnten. Bewertet ist der Eintrag mit CVSS 3.1 als kritisch, der Hersteller bestreitet die Schwachstelle.

Laut Offenlegung riefen die generierten Frontends die Datenbank-API direkt mit dem öffentlichen anon-Schlüssel auf und verließen sich allein auf RLS. Wo Policies fehlten oder zu weit gefasst waren, genügte eine abgewandelte Anfrage aus dem Browser. Ein automatisierter Durchlauf vom 21. März 2025 untersuchte so 1.645 Lovable-Projekte, bei 170 kamen Daten zurück (Stellungnahme zur Offenlegung, 2025). Genannt werden Namen, E-Mail-Adressen, API-Schlüssel für Drittdienste und Zahlungsstatus.

Was zur fairen Einordnung gehört

• Der CVE-Eintrag vermerkt, dass Lovable die Schwachstelle bestreitet: Der Schutz der Anwendungsdaten liege bei den Kunden.
• Die Offenlegung stammt nach eigener Angabe von einem Mitarbeiter von Replit, einem Anbieter im selben Segment. Das macht die Zahlen nicht falsch, gehört aber zur Einordnung.
• Heute läuft bei Lovable beim Veröffentlichen ein Basis-Scan mit RLS-Linting, ein tieferer Scan ist auf Anforderung verfügbar. Die Dokumentation sagt selbst, dass diese Werkzeuge keine vollständige Sicherheit gewährleisten können.

05

Liegen geheime Schlüssel in Ihrem Frontend?

Alles, was im Browser ankommt, kann jeder Besucher lesen, auch in minimiertem JavaScript. Öffentliche Schlüssel wie der Publishable Key von Supabase sind dafür gedacht. Geheime Schlüssel für die Datenbank, für Sprachmodelle, Zahlungs- oder Maildienste gehören dagegen ausschließlich in serverseitige Funktionen mit hinterlegtem Secret.

Ein Supabase Secret Key (sb_secret_..., früher service_role) umgeht jede RLS-Policy, Supabase weist ihn im Browser inzwischen mit HTTP 401 ab. Schlüssel anderer Dienste haben diesen Schutz nicht. Der typische Weg ins Frontend sind Umgebungsvariablen: In Vite-Projekten, also auch bei Lovable, landet alles mit dem Präfix VITE_ im ausgelieferten Code. Ein VITE_OPENAI_API_KEY ist deshalb eine öffentliche Angabe.

1. In den Entwicklerwerkzeugen des Browsers unter „Quellen“ die geladenen Skripte nach sb_secret_, service_role, sk- und Bearer durchsuchen.
2. Repository und Historie mit den Befehlen unten durchsuchen: Ein einmal committeter Schlüssel bleibt in alten Commits lesbar.
3. Im Reiter „Netzwerk“ prüfen, welche Dienste mit geheimem Schlüssel der Browser direkt aufruft.

# Aktueller Stand des Repositorys
git grep -n -I -E "sb_secret_|service_role|sk-[A-Za-z0-9]{10,}|VITE_[A-Z0-9_]*(SECRET|TOKEN|PRIVATE)"

# Gesamte Historie aller Branches, auch längst gelöschte Dateien
git log --all -p | grep -n -E "sb_secret_|service_role|sk-[A-Za-z0-9]{10,}"

06

Warum fehlen Migrationen, und woran merken Sie das?

Migrationen sind versionierte SQL-Dateien, die jede Schemaänderung festhalten. Wird das Schema direkt im Dashboard oder vom Werkzeug geändert, existiert der Stand nur in der laufenden Datenbank: keine identische Testumgebung, kein sauberes Zurücknehmen. Prüfen Sie, ob der Ordner supabase/migrations existiert und die Datenbank vollständig beschreibt.

Supabase empfiehlt, jede Schemaänderung, auch kleine, über Migrationsdateien zu führen statt direkt über Dashboard oder SQL-Editor, und hält angewendete Migrationen in supabase_migrations.schema_migrations fest. In Prototypen ist oft das Gegenteil passiert: Tabellen im Dialog angelegt, Spalten im Dashboard ergänzt, eine Policy zur Fehlersuche gelockert.

supabase link --project-ref <PROJECT_REF>
supabase db pull                          # heutiges Schema als Ausgangsmigration sichern
supabase db diff -f aenderungen_dashboard # im Dashboard gemachte Änderungen erfassen
supabase migration new rls_bestellungen   # neue, leere Migrationsdatei anlegen
supabase db reset                         # lokal alle Migrationen von Grund auf anwenden
supabase db push                          # Migrationen auf das entfernte Projekt anwenden

Selbsttest: Baut supabase db reset aus den Migrationen lokal ein Schema, das der Produktion entspricht? Wenn nicht, ist die Historie unvollständig. Die langfristigen Folgen beschreibt Technische Schulden in KI-generiertem Code erkennen.

07

Ist die Berechtigung nur in der Oberfläche umgesetzt?

Prüfen Sie, ob der Code Schaltflächen und Seiten nur ausblendet, die Rolle aber nicht dort prüft, wo die Daten liegen. Wer die Anfrage im Browser nachbaut, umgeht jede Oberfläche. Wirksam ist eine Berechtigung erst, wenn Datenbank oder Server sie bei jeder Anfrage durchsetzen, egal woher die Anfrage kommt.

Bei Supabase lassen sich Policies auf Basis von user_metadata umgehen, weil Nutzer diese Metadaten selbst bearbeiten können; der Advisor meldet das als rls_references_user_metadata. Rollen gehören in eine eigene Tabelle.

create table public.rollen (
  user_id uuid primary key references auth.users (id) on delete cascade,
  rolle text not null check (rolle in ('admin', 'mitarbeiter'))
);
alter table public.rollen enable row level security;

-- Nutzer lesen nur die eigene Rolle; ohne Schreib-Policy vergibt niemand Rollen über die API
create policy "Eigene Rolle lesen"
on public.rollen for select to authenticated
using ( (select auth.uid()) = user_id );

-- Rechnungen sehen nur Administratoren
create policy "Admins lesen Rechnungen"
on public.rechnungen for select to authenticated
using (
  exists (
    select 1 from public.rollen r
    where r.user_id = (select auth.uid())
      and r.rolle = 'admin'
  )
);

Selbsttest: Mit einem Konto ohne Sonderrechte eine Datenanfrage aus dem Reiter „Netzwerk“ kopieren und die Kennung ändern, etwa id=eq.124 statt id=eq.123, oder eine Tabelle abfragen, die nur Administratoren sehen sollen. Kommen Daten zurück, ist die Berechtigung nur Kulisse.

08

Was steht in Ihren Protokollen?

Beim Bauen helfen Ausgaben wie console.log(user) bei der Fehlersuche. Veröffentlicht landen sie in der Browserkonsole jedes Besuchers oder in den Funktionsprotokollen der Plattform, samt E-Mail-Adressen, Tokens und Formularinhalten. Protokolle sollen Ereignisse nachvollziehbar machen, nicht Personendaten sammeln, und das lässt sich vor dem Livegang prüfen.

Browserausgaben sieht jeder, und sie verraten Tabellennamen, die einen Angriff erleichtern. Serverprotokolle können mehr Personen lesen als die eigentlichen Daten, und sie folgen eigenen Aufbewahrungsregeln.

git grep -n -E "console\.(log|debug|info)\(" -- src supabase/functions

Die datenschutzrechtliche Seite beschreibt DSGVO-konforme KI.

09

Kommen Sie mit Code und Daten wieder heraus?

Beim Code ja: Lovable synchronisiert mit GitHub, Bolt und Replit bieten einen Download als ZIP. Schwieriger sind Daten, Secrets und Plattformdienste wie Anmeldung, Dateispeicher und serverseitige Funktionen. Testen Sie den Umzug, solange nichts drängt, und nicht erst, wenn sich Tarif, Bedingungen oder Anforderungen ändern.

10

In welcher Reihenfolge gehen Sie die Punkte an?

Zuerst, was heute schon Daten offenlegen kann: RLS und geheime Schlüssel. Danach Migrationen und Berechtigungen, weil jede weitere Änderung darauf aufbaut. Protokolle und Portabilität folgen, bevor der Betrieb beginnt. Die Entscheidungshilfe führt durch die Fragen und zeigt, worüber Sie als Nächstes sprechen sollten.

Soll die IT eine Fachbereichs-Anwendung übernehmen, hilft Der Fachbereich hat eine App gebaut. Was Untersuchungen über generierten Code messen, fasst Was Studien über die Qualität KI-generierten Codes zeigen zusammen, Haftungsfragen ordnet Wer haftet, wenn KI-generierter Code Schaden anrichtet? ein.

iiterate Technologies GmbH aus Adenau entwickelt Individualsoftware und KI-Anwendungen von der Architektur über die Umsetzung bis zum Betrieb, auf Kundeninfrastruktur oder in EU-Hosting, und übergibt mit Quellcode und Dokumentation. Wenn Sie über Ihre Anwendung sprechen möchten: Kontakt.