Sicherheit für KI-gebaute Apps

Was „Vibe-Coding-Sicherheit" bedeutet

KI-Tools (Lovable, Bolt, v0, Cursor, Replit, Windsurf) erzeugen Apps mit einer sehr bestimmten Architektur: Der Browser spricht direkt mit der Datenbank (Supabase, Firebase) und mit externen Diensten (Stripe, OpenAI, Resend). Dazwischen gibt es fast keinen eigenen Server. Das beschleunigt alles, verschiebt die Sicherheit aber von deinem Code in deine Konfiguration: Was dich schützt, sind die Datenbankregeln, die HTTP-Header, die CORS-Richtlinie und die Frage, welche Keys wo liegen, nicht wie sauber der Code der Oberfläche ist.

Diese Teile sind standardmäßig nicht korrekt eingerichtet, und die KI konfiguriert sie nur selten, wenn du nicht danach fragst. Ihr Ziel ist, dass die App in der Demo läuft, und eine Tabelle ohne Einschränkungen oder ein ins Frontend kopierter Key „funktionieren" tadellos. Das Ergebnis sind Apps, die makellos aussehen und Daten oder Keys für jeden preisgeben, der weiß, wo er suchen muss: Man muss kein Hacker sein, es reicht, die Entwicklertools des Browsers zu öffnen.

Deshalb bedeutet „Vibe-Coding-Sicherheit" nicht, Kryptografie zu lernen oder ein Audit zu beauftragen. Es bedeutet, das halbe Dutzend Lücken zu kennen, die sich in fast jeder KI-gebauten App wiederholen, sie von außen prüfen zu können und dieselbe KI mit präzisen Anweisungen beheben zu lassen.

Warum KI-gebaute Apps an denselben Stellen scheitern

Es gibt ein Muster. Die KI optimiert darauf, dass der Code kompiliert und der Bildschirm Daten zeigt, nicht darauf, dass ein Fremder sie nicht sehen kann. Wenn eine Abfrage an Berechtigungen scheitert, ist die kürzeste Lösung, die störende Berechtigung zu entfernen: Row Level Security deaktivieren, eine Regel setzen, die alles erlaubt, oder den Admin-Key verwenden. Und die KI wählt die kürzeste Lösung.

Der zweite Grund: Sie kopiert Vorlagen. Variablen mit dem Präfix NEXT_PUBLIC_, VITE_ oder NUXT_PUBLIC_ werden absichtlich an den Browser geschickt, und viele Beispiele im Internet legen dort Keys ab, die den Server nie verlassen dürften. Firebase-Regeln im Testmodus erlauben jedem 30 Tage lang Lesen und Schreiben, und Apps gehen mit diesem Modus live. Sicherheits-Header tauchen in fast keinem Tutorial auf, also tauchen sie auch in der App nicht auf.

Der dritte: Niemand zeichnet das Bedrohungsmodell. Wer mit KI baut, denkt an den Nutzer, den er will, nicht an den Besucher, der den Network-Tab öffnet, die API-URL kopiert und den Filter entfernt. In diesem Guide geht es darum, sich zehn Minuten lang in diesen Besucher hineinzuversetzen.

Die sieben Lücken, die KI-gebaute Apps am häufigsten treffen

API-Keys im Browser. Wenn du einen Dienst „verbindest", landet der Key im Client-JavaScript, wo er für immer öffentlich ist: Jeder kann ihn im Quelltext lesen und auf deine Kosten nutzen (OpenAI-Rechnungen, E-Mails von deiner Domain, Zugriff auf deine Daten). Die einzigen Keys, die in den Client dürfen, sind die dafür gedachten, etwa der anon- oder publishable-Key von Supabase, der öffentliche Stripe-Key oder die Firebase-Konfiguration, und auch nur, wenn die Regeln dahinter stimmen.

Fehlende oder schwache Datenbankregeln. Ohne Row Level Security auf jeder Supabase-Tabelle, oder mit einer Policy, die alles erlaubt, liest und beschreibt jeder deine Daten ohne Login, über dieselbe API, die deine App nutzt. In Firebase tun Regeln im Testmodus oder mit allow read, write: if true dasselbe. Es ist die schwerste und häufigste Lücke, und sie war der Ursprung der Schwachstelle CVE-2025-48757, die Nutzerdaten in mit Lovable gebauten Apps offenlegte.

Zu freizügiges CORS. Eine API, die mit Access-Control-Allow-Origin jede Herkunft spiegelt und zusätzlich Credentials erlaubt, lässt eine bösartige Website im Namen deiner Nutzer Anfragen stellen und die Antworten lesen. Der Platzhalter bei einer öffentlichen API ohne Cookies ist akzeptabel; die Herkunft mit Credentials zu spiegeln, niemals.

Fehlende Sicherheits-Header. Ohne Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (oder frame-ancestors), X-Content-Type-Options, Referrer-Policy und Permissions-Policy ist deine App offen für Clickjacking, Script-Injection, Downgrade auf HTTP und das Durchsickern interner URLs. Sie werden auf dem Server oder beim Hoster (Vercel, Netlify, Cloudflare) in zehn Zeilen konfiguriert.

Zugängliche sensible Dateien. Eine versehentlich veröffentlichte .env, ein offenes .git-Verzeichnis, Source Maps, mit denen sich der komplette Quellcode rekonstruieren lässt, Datenbank-Backups oder Admin-Panels ohne Authentifizierung. Sie sind leicht zu finden, weil Angreifer sie auf jeder neuen Domain automatisch suchen.

Falsch konfigurierte Sessions und Cookies. Session-Cookies ohne die Attribute Secure, HttpOnly und SameSite, Tokens im localStorage in Reichweite jedes Skripts oder Sessions, die nie ablaufen. Ein kleines XSS wird zur Kontoübernahme, wenn das Cookie aus JavaScript lesbar ist.

Endpoints, die dem Client vertrauen. API-Routen, die die Nutzer-ID, den Preis oder die Rolle aus dem Request-Body übernehmen, ohne sie auf dem Server zu prüfen. Wenn die Oberfläche den Admin-Button versteckt, die Route aber weiterhin jedem antwortet, schützt der Button nichts.

Was du je nach Stack prüfen solltest

Lovable, Bolt oder v0 mit Supabase. Prüfe, dass alle Tabellen RLS aktiviert haben und Policies pro Operation (select, insert, update, delete) auf Basis von auth.uid(); dass der service_role-Key in keiner öffentlichen Variable steckt; dass private Storage-Buckets Policies haben; und dass Views und RPC-Funktionen die Policies nicht umgehen. Das Supabase-Dashboard enthält einen Security Advisor, der das Gravierendste auflistet.

Cursor, Windsurf oder Replit mit Next.js, Nuxt oder Express auf Vercel. Prüfe, welche Umgebungsvariablen ein öffentliches Präfix tragen, dass API-Routen die Session bei jeder Anfrage validieren und nicht nur in der Oberfläche, dass die Sicherheits-Header definiert sind (vercel.json, next.config oder nuxt.config) und dass in der Produktion keine Source Maps veröffentlicht werden.

Firebase. Ersetze die Testmodus-Regeln durch Regeln auf Basis von request.auth, in Firestore wie im Storage; aktiviere App Check, damit nur deine App deine Dienste nutzen kann; und stelle sicher, dass Cloud Functions, die etwas Sensibles tun, das Token des Nutzers prüfen, bevor sie handeln.

Dass die App „gut aussieht", heißt nicht, dass sie sicher ist

Einen Button in der Oberfläche zu verstecken schützt nichts: Die Anfrage bleibt eine öffentliche URL, die jeder direkt aus der Browserkonsole oder mit curl aufrufen kann. Echte Sicherheit steckt auf dem Server und in der Datenbank, nicht in dem, was der Nutzer sieht. Deshalb ist die Prüfung von außen —so, wie es ein Angreifer täte— der einzige Weg, um zu wissen, was wirklich offenliegt.

Auch das grüne HTTPS-Schloss reicht nicht. HTTPS verschlüsselt den Weg zwischen Browser und Server; es sagt nichts darüber, ob der Server Daten an die Falschen herausgibt. Eine App mit perfektem Zertifikat und einer Tabelle ohne RLS ist eine App mit einem perfekt verschlüsselten Leck.

Wie du es in zehn Minuten selbst prüfst

Erstens: Öffne deine Website und sieh dir den Quelltext an (Rechtsklick, Seitenquelltext anzeigen). Suche nach key, secret, sk_, service_role und den Namen der Dienste, die du nutzt. Alles, was dort auftaucht, ist öffentlich.

Zweitens: Geh bei geöffneter App in den Network-Tab der Entwicklertools, finde eine Anfrage an deine Datenbank oder API, kopiere die URL und öffne sie in einem Inkognito-Fenster. Liefert sie Daten ohne Session, ist dieser Endpoint offen. Entferne eingeloggt den Nutzerfilter aus der URL: Liefert sie Zeilen anderer, sind die Policies falsch.

Drittens: Fordere die Header deiner Domain mit curl -I https://deinedomain.de an und prüfe, ob Content-Security-Policy, Strict-Transport-Security und X-Frame-Options oder frame-ancestors erscheinen. Fehlt einer, ist er nicht konfiguriert.

Viertens: Versuche, /.env, /.git/config, /config.json und eine .js.map-Datei aus deinem Bundle zu öffnen. Alle müssen 404 oder 403 liefern.

Fünftens: Lege zwei Testkonten an und prüfe, dass keines die Daten des anderen sieht, ändert oder löscht, hochgeladene Dateien eingeschlossen. Es ist der langweiligste Test und der, der die meisten Lücken findet.

Wie du es in 30 Sekunden prüfst

Scanaris automatisiert diese Tests und einige mehr. Es scannt deine veröffentlichte Website schreibgeschützt: Es fasst deinen Code nicht an, injiziert nichts und versucht nichts auszunutzen; es sieht sich an, was ohnehin öffentlich ist, so wie es jeder von außen könnte. Es prüft Header, Cookies, das TLS-Zertifikat, CORS, Secrets im JavaScript, sensible Dateien, Technologien mit bekannten Versionen, deine Supabase-Regeln, wenn du ihm eine schreibgeschützte Verbindung gibst, und außerdem, wie Google dich sieht und wie KIs dich lesen.

Jeder Fund kommt nach Auswirkung sortiert (Kritisches zuerst), in normaler Sprache erklärt und mit einem Fix-Prompt, den du direkt in Lovable, Cursor oder dein Tool einfügen kannst. Füge deine URL ein, warte eine halbe Minute und du weißt, ob du deine App beruhigt teilen kannst.

Worauf du nach dem Launch achten solltest

Sicherheit ist kein Zustand, sondern eine Gewohnheit. Jede neue Tabelle kommt ohne RLS zur Welt, jede neue Funktion kann einen Key an die falsche Stelle legen und jede Abhängigkeit altert. Plane einen regelmäßigen Re-Scan und sieh dir die Unterschiede an, nicht den ganzen Bericht: Wichtig ist, was sich seit dem letzten Mal geöffnet hat.

Behalte auch im Blick, was nicht vom Code abhängt: dass Zertifikat und Domain nicht ablaufen, dass die Website antwortet und dass im Browser deiner Nutzer keine Skripte auftauchen, die du nicht eingebaut hast. Und wenn du etwas behebst, prüfe es erneut von außen: Die Korrektur zählt, wenn der Scanner sie nicht mehr sieht, nicht wenn die KI sagt, es sei erledigt.

Für deinen Stack tiefer einsteigen

Wichtige Sicherheitschecks

Verwandte Guides

Häufig gestellte Fragen