Vibe-Coding-Apps absichern

Mit Lovable, Bolt, v0 oder Replit baut eine Fachabteilung ein Kundenportal oder ein internes Werkzeug an einem Nachmittag. Mit Cursor, Claude Code oder Codex geht es im Entwicklerteam ähnlich schnell. Die App läuft. Ob sie Daten oder Schlüssel preisgibt, hat oft niemand geprüft. Bleibt das offen, sind Kundendaten für jeden lesbar oder Unbefugte nutzen Ihre Schlüssel auf Ihre Rechnung. Aus einem Versehen wird dann schnell eine meldepflichtige Datenpanne.

Die Verantwortung liegt beim Unternehmen, das die App betreibt. Lovable hat das 2025 selbst so vertreten, als eine Lücke in vielen Lovable-Apps bekannt wurde (CVE-2025-48757): Für die Daten einer App sei der jeweilige Kunde zuständig.

Typische Lücken

• Schlüssel im Browser-Code. Zugangsschlüssel landen leicht in Variablen wie VITE_ oder NEXT_PUBLIC_. Beim Bauen landen sie in den JavaScript-Dateien, die jeder Besucher herunterlädt. Escape hat 2025 über 5.600 öffentlich erreichbare Vibe-Coding-Apps untersucht und über 400 offen liegende Schlüssel gefunden, darunter Supabase-Generalschlüssel (Escape, Oktober 2025).
• Datenbank ohne Zugriffsregeln. Viele dieser Apps sprechen ihre Supabase- oder Firebase-Datenbank direkt aus dem Browser an. Fehlen die Regeln, wer welche Zeile lesen darf, kann jeder alle Daten abrufen. Bei der Plattform Moltbook fand Wiz so einen Schlüssel im JavaScript und dahinter eine offene Datenbank mit 1,5 Mio. API-Tokens und 35.000 E-Mail-Adressen (Wiz, Februar 2026).
• KI-Aufrufe direkt aus dem Browser. Damit ein Chat oder eine Zusammenfassung funktioniert, steht der Schlüssel für OpenAI oder Anthropic im Frontend. Jeder Besucher kann ihn kopieren und auf Ihre Kosten nutzen.
• Fehlende Grundeinstellungen. Schutz-Einstellungen für den Browser, lesbarer Original-Quellcode über Source Maps und veraltete Bibliotheken bleiben meist so, wie das Werkzeug sie erzeugt hat.
• Rechte nur in der Oberfläche. Ein ausgeblendeter Knopf ersetzt keine Prüfung auf dem Server. Wer die Schnittstelle direkt aufruft, umgeht ihn.

Was Hullwise davon findet

Der Check liest Ihre Startseite und die JavaScript-Dateien, die sie selbst von Ihrer Domain einbindet, so wie jeder Browser sie lädt, bei Vite-Apps auch Teile, die beim Seitenwechsel nachgeladen werden. Bei Apps aus Vite oder Next.js landen die Schlüssel in diesen Dateien. Wir probieren keine Pfade aus und benutzen nichts, was wir finden. Die Grenzen stehen in Was wir nicht prüfen.

Im Ergebnis steht auch, welche Plattform wir erkannt haben, etwa Lovable, Bolt, v0, Replit, Supabase oder Firebase. Apps aus Cursor, Claude Code oder Codex tragen keine Spur des Werkzeugs. Bei ihnen erkennen wir Hoster und Framework, etwa Vercel und Next.js. Läuft eine App unter einer Adresse wie name.lovable.app, gilt der Mail-Schutz im Ergebnis für die Domain der Plattform. Prüfen Sie dafür zusätzlich Ihre Firmendomain.

Ein Schlüssel ist offen: die ersten Schritte

Gehen Sie davon aus, dass der Schlüssel schon kopiert wurde. Laut GitGuardian waren 64 % der Schlüssel, die 2022 als gültig bestätigt wurden, 2026 immer noch nicht gesperrt (State of Secrets Sprawl 2026).

1. Sperren. Widerrufen Sie den Schlüssel beim Anbieter sofort, noch bevor der Code angepasst ist. Ihn nur aus dem Code zu löschen reicht nicht, er steckt noch in alten Dateien, Kopien und im Git-Verlauf.
2. Neu erzeugen. Legen Sie beim Anbieter einen neuen Schlüssel mit möglichst wenigen Rechten an.
3. Nur serverseitig verwenden. Der neue Schlüssel gehört in eine Server-Funktion und dort in die geschützten Einstellungen des Hosters, etwa eine Supabase Edge Function, eine Funktion bei Vercel oder Netlify oder einen API-Endpunkt in Next.js. Ein Präfix wie VITE_ oder NEXT_PUBLIC_ darf er nicht tragen.
4. Logs prüfen. Sehen Sie nach, ob und wofür der alte Schlüssel benutzt wurde: Nutzung und Kosten bei OpenAI oder Anthropic, API-Logs in Supabase, Ereignisse in Stripe, CloudTrail bei AWS.
5. Meldepflicht prüfen. Konnte jemand mit dem Schlüssel personenbezogene Daten abrufen, kann das eine Datenpanne sein. Die DSGVO verlangt dann eine Meldung an die Aufsicht binnen 72 Stunden (Art. 33). Einrichtungen unter NIS2 geben bei erheblichen Sicherheitsvorfällen binnen 24 Stunden eine erste Meldung an das BSI ab (§ 32 BSIG). Ob eine Pflicht greift, klären Ihr Datenschutzbeauftragter oder Ihre Rechtsberatung.
6. Neu veröffentlichen und neu prüfen. Starten Sie danach einen neuen Check. Der Befund muss verschwinden.

In Lovable oder Bolt können Sie den Assistenten den Umbau machen lassen, zum Beispiel so:

Alle Aufrufe an OpenAI in eine Supabase Edge Function verschieben. Der API-Schlüssel steht nur dort als Secret, nicht im Frontend und nicht in einer Variable mit VITE_.

Prüfen Sie das Ergebnis trotzdem: Der Schlüssel darf danach in keiner Datei mehr stehen, die der Browser lädt.

Zugriffsregeln in Supabase (RLS)

Supabase gibt jeder App zwei Arten von Schlüsseln. Der öffentliche (anon oder sb_publishable) darf im Browser stehen. Er schützt die Daten aber nur, wenn auf jeder Tabelle Zugriffsregeln aktiv sind, die sogenannte Row Level Security. Ohne sie kann jeder mit diesem Schlüssel alle Zeilen lesen und je nach Einstellung auch ändern. Der geheime Schlüssel (service_role oder sb_secret) umgeht alle Regeln und gehört nie in den Browser.

Wie oft das schiefgeht, zeigt die Lücke in Lovable-Apps von 2025: Ein Forscher prüfte 1.645 veröffentlichte Apps, 170 davon hatten offene Tabellen (Matt Palmer, CVE-2025-48757). Diese Lücke sieht ein Check von außen nicht. Wir melden nur, dass die App ihre Datenbank direkt anspricht.

Selbstcheck in einer Minute

Öffnen Sie in Ihrem Supabase-Projekt den SQL Editor, fügen Sie diese Abfrage ein und klicken Sie auf Run. Sie liest nur und ändert nichts. Jede Zeile im Ergebnis ist eine Tabelle ohne Zugriffsregeln oder eine Regel, die jedem Besucher alles erlaubt. Ist das Ergebnis leer, haben wir nichts gefunden. Ob Ihre Regeln inhaltlich passen, etwa nur eigene Zeilen zeigen, sagt die Abfrage nicht.

-- Hullwise-Selbstcheck: nur lesend, ändert nichts. Leeres Ergebnis = nichts gefunden.
select c.relname as tabelle,
       'Row Level Security ist aus' as problem
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p') and not c.relrowsecurity
union all
select p.tablename,
       'Regel "' || p.policyname || '" erlaubt ' || p.cmd || ' für alle ohne Bedingung'
from pg_policies p
where p.schemaname = 'public'
  and (p.roles && array['public', 'anon']::name[])
  and (p.qual = 'true' or p.with_check = 'true')
order by 1;

1. Öffnen Sie im Supabase-Dashboard den Table Editor. Jede Tabelle mit echten Daten muss RLS eingeschaltet haben. Auch der Security Advisor im Dashboard listet Tabellen ohne RLS auf.
2. Schalten Sie RLS ein und legen Sie für jede Tabelle fest, wer welche Zeilen lesen und schreiben darf.
3. Testen Sie abgemeldet: Ohne passende Regel darf die App keine fremden Daten mehr anzeigen.

alter table public.bestellungen enable row level security;

create policy "Kunden lesen nur eigene Bestellungen"
  on public.bestellungen for select
  using (auth.uid() = kunde_id);

Ob die Regeln vollständig sind, prüft das Audit für 1.500 € je Anwendung, nachdem Sie nachgewiesen haben, dass Ihnen die Domain gehört.

Security Rules in Firebase

Bei Firebase steht die Konfiguration mit apiKey, authDomain und projectId immer im Browser-Code. Das ist so gedacht, der Schlüssel darin ist kein Geheimnis. Was wer lesen und schreiben darf, regeln allein die Security Rules von Firestore, Realtime Database und Storage. Steht dort noch der Testmodus oder eine Regel wie allow read, write: if true, kann jeder mit der Konfiguration aus Ihrem Code alle Daten lesen und ändern. Von außen sehen wir die Regeln nicht, deshalb melden wir nur einen Hinweis.

1. Öffnen Sie in der Firebase-Konsole bei Firestore, Realtime Database und Storage jeweils den Reiter Regeln.
2. Erlauben Sie Zugriffe nur angemeldeten Nutzern und nur auf eigene Daten, etwa mit request.auth.uid.
3. Prüfen Sie Änderungen vorher im Rules Playground der Konsole.
4. Beschränken Sie den API-Schlüssel in der Google Cloud Console auf Ihre Domain und die Firebase-Dienste.

Regeln für Mitarbeitende

Laut Bitkom haben nur 23 % der Unternehmen Regeln für den Einsatz generativer KI aufgestellt (Bitkom, Oktober 2025). Für Apps, die mit KI gebaut werden, reichen wenige Regeln:

1. Jede App, die Kunden- oder Firmendaten verarbeitet, wird vor dem Livegang der IT oder dem Informationssicherheitsbeauftragten gemeldet.
2. Gebaut wird mit Firmenkonten, nicht mit privaten Zugängen. Das empfehlen auch BSI und ANSSI für KI-Programmierassistenten (BSI, Oktober 2024).
3. Echte Schlüssel gehören nie in einen Prompt, einen Chat oder eine Variable mit VITE_ oder NEXT_PUBLIC_. Sie stehen nur in den geschützten Einstellungen des Hosters.
4. Für jeden KI-Schlüssel gibt es beim Anbieter ein Ausgabenlimit.
5. Vor dem ersten echten Datensatz ist RLS auf allen Tabellen eingeschaltet.
6. Generierter Code wird vor dem Livegang gelesen und getestet. Danach läuft jede App durch einen Check.

Wie Sie Ihre Apps prüfen

Den ersten Überblick gibt der kostenlose Check auf der Startseite. Das Paket Business prüft Ihre Apps jede Woche und schickt eine Mail, sobald sich eine Note verschlechtert. Der Verlauf dient als Nachweis für die regelmäßige Überprüfung. Mehr unter Preise.

Hullwise prüft die laufende App, nicht Ihr Repository. Schlüssel im Git-Verlauf findet ein Secret-Scanner im Repository, etwa die Funktion Ihres Git-Anbieters. Wer mit Cursor, Claude Code oder Codex arbeitet, sollte ihn einschalten: Laut GitGuardian enthielten Commits mit Unterstützung von Claude Code 2025 in rund 3,2 % der Fälle ein Geheimnis, etwa doppelt so oft wie der Durchschnitt (State of Secrets Sprawl 2026).

Noch Fragen? Schreiben Sie uns.