Wie man KI-generierte Code sichert — Vibe Coding Security Checklist

Wenn du eine App mit Claude oder Cursor zusammengebaut hast und sie gerade einem zahlenden Client übergeben willst, stopp. KI-generierter Code enthält vorhersehbare Sicherheitslücken — exponierte API-Schlüssel, fehlende Eingabevalidierung, Standarddatenbankberechtigungen, die es jedem Nutzer ermöglichen, die Daten aller anderen zu sehen. Das sind keine Randfälle. Sie passieren in fast jedem ersten Durchlauf von KI-generierter Codebasis.

Diese Anleitung ist deine Sicherheitscheckliste vor dem Launch. Gehe sie Schritt für Schritt durch, bevor ein echter Nutzer deine App anfasst. Sie ist für den häufigsten Vibe-Coding-Stack geschrieben (Next.js + Supabase + Vercel), aber die Prinzipien gelten unabhängig von deinen Tools.

Warum KI-generierter Code Sicherheitsprobleme hat

KI-Modelle optimieren für „funktioniert es?" nicht für „ist es sicher?". Wenn du Claude sagst „baue mir einen Task-Manager mit Benutzerkonten", wird es Code generieren, der Nutzer erstellt, Aufgaben speichert und sie anzeigt. Was es wahrscheinlich nicht automatisch macht: sicherstellen, dass Nutzer A die Aufgaben von Nutzer B nicht sehen kann, validieren, dass Eingabefelder keine bösartigen Skripte akzeptieren, deine API-Schlüssel vor den Browser-Entwicklertools verstecken oder Rate Limiting hinzufügen, um zu verhindern, dass jemand deine Endpoints bombardiert.

Das sind keine Fehler der KI — es sind Lücken in der Eingabeaufforderung. Die KI erstellt, was du gefordert hast. Du hast wahrscheinlich nicht um Sicherheit gebeten, weil du dich auf Features konzentriert hast. Jetzt ist es Zeit, zurück zu gehen und Sicherheit hinzuzufügen.

Schritt 1: Überprüfe deine Umgebungsvariablen

Das ist der häufigste und gefährlichste Fehler in Vibe-Coding-Apps. Suche nach hardcodierten API-Schlüsseln, Datenbankberechtigungen oder Geheimnissen in deinem Projekt.

Worauf du achten solltest: Durchsuche deine Codebasis nach Strings, die mit sk-, eyJ, sbp_, supabase, postgres:// oder anderen langen zufällig aussehenden Strings beginnen. Überprüfe diese Dateien besonders: Alle Dateien in deinem /app oder /pages Verzeichnis, alle Komponentendateien, deine next.config.js und alle Utility-Dateien.

Die Lösung: Verschiebe jeden Geheimschlüssel in Umgebungsvariablen. In Next.js werden nur Variablen mit dem Präfix NEXT_PUBLIC_ für den Browser exponiert. Deine Datenbankberechtigungen, Service-Role-Schlüssel und API-Geheimnisse sollten dieses Präfix niemals haben.

# .env.local (NIEMALS diese Datei committen)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Diese sind okay, um für den Browser zu exponieren:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Überprüfung: Überprüfe deine .gitignore Datei und stelle sicher, dass sie .env.local enthält. Wenn du bereits Geheimnisse in Git committed hast, sind sie in deiner Historie — auch nach dem Löschen — also regeneriere (rotiere) jeden exponierten Schlüssel sofort.

Schritt 2: Aktiviere Row-Level Security in Supabase

Das ist der kritischste Schritt, wenn du Supabase verwendest. Standardmäßig haben Supabase-Tabellen keine Zugriffsbeschränkungen — jeder mit deinem Anon-Schlüssel kann jede Zeile in jeder Tabelle lesen und schreiben. Das bedeutet, dass Nutzer A die Daten von Nutzer B mit einem einfachen API-Aufruf sehen kann.

Die Lösung: Aktiviere Row-Level Security (RLS) auf jeder Tabelle und erstelle dann Richtlinien, die den Zugriff einschränken.

Gehe zu deinem Supabase-Dashboard → Table Editor → wähle jede Tabelle → klicke auf „RLS Disabled" um es zu aktivieren. Füge dann Richtlinien hinzu:

Für eine typische App, in der Nutzer nur ihre eigenen Daten sehen sollten, erstelle eine SELECT-Richtlinie: auth.uid() = user_id. Erstelle ähnliche Richtlinien für INSERT, UPDATE und DELETE.

Test: Melde dich als Nutzer A an und versuche auf die Daten von Nutzer B über die API zuzugreifen. Wenn du sie sehen kannst, sind deine Richtlinien falsch. Supabase hat einen SQL-Editor, in dem du Richtlinien direkt testen kannst.

Häufiger KI-Fehler: Claude generiert oft Supabase-Anfragen mit dem service_role Schlüssel (der RLS umgeht) anstatt mit dem anon Schlüssel mit geeigneten RLS-Richtlinien. Überprüfe, dass dein client-seitiger Code nur den Anon-Schlüssel verwendet. Der Service-Role-Schlüssel sollte nur in server-seitigen Code (API-Routen, Server-Aktionen) existieren und niemals für den Browser exponiert werden.

Schritt 3: Implementiere Authentifizierung richtig

KI-generierter Auth-Code funktioniert oft, nimmt aber Abkürzungen. Überprüfe diese spezifischen Probleme:

Sitzungsverwaltung: Stelle sicher, dass Sitzungen ablaufen. Überprüfe, dass deine Auth-Einrichtung ein sinnvolles Sitzungs-Timeout enthält (Supabase-Standardwerte sind im Allgemeinen in Ordnung, aber überprüfe). Stelle sicher, dass sich Abmelden tatsächlich aus der Sitzung abmelden, nicht nur den lokalen Cookie löscht.

Passwortanforderungen: Wenn du E-Mail/Passwort-Auth hast, erzwinge eine Mindestpasswortlänge (8+ Zeichen). Supabase handhabt dies in deinen Projekteinstellungen → Authentication → Password Requirements.

Geschützte Routen: Jede Seite, die benutzerspezifische Daten zeigt, benötigt Authentifizierungs-Middleware. In Next.js App Router erstelle eine Middleware, die auf eine gültige Sitzung prüft und nicht authentifizierte Nutzer zur Login-Seite umleitet. Verlasse dich nicht nur auf client-seitige Prüfungen — ein Nutzer kann diese umgehen, indem er deine API direkt aufruft.

E-Mail-Bestätigung: Aktiviere E-Mail-Bestätigung in Supabase-Auth-Einstellungen. Das verhindert, dass Leute Konten mit gefälschten E-Mail-Adressen erstellen und fügt eine grundlegende Ebene der Kontovalidität hinzu.

Schritt 4: Validiere alle Eingaben

KI-generierte Formulare haben normalerweise grundlegende Validierung (erforderliche Felder, E-Mail-Format), schützen aber selten vor bösartigen Eingaben.

Was du hinzufügen solltest:

Server-seitige Validierung auf jedem API-Endpoint. Vertraue niemals nur auf client-seitige Validierung — sie kann durch direkte API-Anfragen umgangen werden. Verwende eine Validierungsbibliothek wie Zod (für TypeScript), um Schemas für jeden Datensatz zu definieren, den deine App akzeptiert.

Bereinige HTML in benutzergenerierten Inhalten, die angezeigt werden. Wenn deine App Kommentare, Beschreibungen oder andere Textfelder hat, die im Browser gerendert werden, verwende eine Bibliothek wie DOMPurify, um gefährliche Skripte zu entfernen. Ohne das kann jemand JavaScript injizieren, das die Sitzungen anderer Nutzer stiehlt (Cross-Site-Scripting / XSS).

Begrenze die Dateigröße und -typen, wenn deine App Datei-Uploads akzeptiert. KI-generierte Upload-Handler haben oft keine Limits, was bedeutet, dass jemand eine 2-GB-Datei oder eine ausführbare Datei hochladen könnte. Füge Größenlimits (5MB ist für die meisten Apps sinnvoll) hinzu und beschränke Dateitypen auf das, was du wirklich brauchst (Bilder, PDFs, etc.).

Schritt 5: Sichere deine API-Routen

Überprüfe jeden API-Route oder Server-Action in deiner App auf diese Probleme:

Authentifizierung auf jedem Endpoint. Jeder API-Route, der Nutzerdaten zurückgibt oder ändert, sollte zunächst die Sitzung des Nutzers überprüfen. KI generiert oft API-Routes, die Anfragen von jedem akzeptieren.

Autorisierung über Authentifizierung hinaus. Auch nachdem du bestätigt hast, dass ein Nutzer angemeldet ist, überprüfe, dass er auf die spezifische Ressource zugreifen darf, die er anfordert. „Nutzer A ist angemeldet" bedeutet nicht „Nutzer A kann Nutzer B's Profil bearbeiten". Überprüfe die Eigentümerschaft bei jedem Datenzugriff.

Rate Limiting. Ohne Rate Limiting kann jemand Tausende Anfragen pro Sekunde an deine API senden, entweder um Daten zu scrapen oder deinen Server zu überlasten. Füge grundlegende Rate Limiting mit einer Bibliothek wie rate-limiter-flexible hinzu oder nutze Verdel's eingebautes Rate Limiting auf Edge Functions.

HTTP-Methoden. Stelle sicher, dass deine API-Routes nur auf die HTTP-Methoden reagieren, auf die sie sollten. Eine Route, die POST-Anfragen handhabt, sollte nicht auch auf DELETE-Anfragen reagieren, es sei denn, du hast das explizit entworfen.

Schritt 6: Überprüfe deine Deployment-Konfiguration

Deine Deployment-Plattform hat Sicherheitseinstellungen, die KI nicht für dich konfiguriert.

Zu überprüfende Vercel-Einstellungen: Aktiviere „Deployment Protection" (erfordert Auth zum Anschauen von Preview-Deployments — verhindert, dass Clients versehentlich Preview-URLs teilen, die unfertiges Werk exponieren). Richte Ausgabenlimits ein, um unerwartete Kosten bei Traffic-Spitzen zu verhindern. Konfiguriere deine erlaubten Domains in CORS-Headers.

Custom Domain und SSL: Wenn du das an einen Client lieferst, richte seine Custom Domain mit HTTPS ein. Vercel und Netlify handeln SSL automatisch. Liefere eine Client-App niemals auf einer .vercel.app Subdomain — es sieht unprofessionell aus und der Client kann sie nicht leicht transferieren.

Headers: Füge Security-Headers zu deiner next.config.js oder vercel.json hinzu: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (verhindert, dass deine Website in iframes eingebettet wird für Clickjacking), Strict-Transport-Security (erzwingt HTTPS). Das sind einmalige Hinzufügungen, die ganze Klassen von Attacken verhindern.

Schritt 7: Führe eine finale Sicherheitsprüfung durch

Bevor du etwas an einen Client übergibst, führe diese kostenlosen Prüfungen durch:

npm audit: Führe npm audit in deinem Projektverzeichnis aus. Es kennzeichnet bekannte Anfälligkeit in deinen Abhängigkeiten. Behebe kritische und High-Severity-Probleme. Führe npm audit fix für automatische Fixes aus, wo verfügbar.

Lighthouse: Öffne deine bereitgestellte Website in Chrome, öffne DevTools, führe ein Lighthouse-Audit aus. Überprüfe den „Best Practices" Score — er erfasst häufige Sicherheitsprobleme wie fehlendes HTTPS, anfällige Bibliotheken und unsichere Headers.

Manuelles Testen: Melde dich als ein Nutzer an, versuche auf die Daten eines anderen Nutzers zuzugreifen, indem du URLs oder API-Aufrufe änderst. Versuche leere Formulare, übergroße Eingaben und Sonderzeichen (wie kodierte XSS-Payloads) abzuschicken. Wenn eines von diesen funktioniert, hast du Probleme zu beheben.

Die Pre-Launch-Checkliste

Drucke das aus und überprüfe jedes Element, bevor du live gehst:

• Alle Geheimnisse in Umgebungsvariablen (keine hardcodierten Schlüssel)
• .env.local in .gitignore (und keine Geheimnisse in Git-Historie)
• Supabase RLS auf jeder Tabelle aktiviert
• RLS-Richtlinien getestet (Nutzer A kann Nutzer B's Daten nicht sehen)
• Client-seitiger Code nutzt nur Anon-Schlüssel (Service-Role-Schlüssel nur server-seitig)
• Authentifizierung auf jedem API-Route
• Autorisierungsprüfungen (Eigentümerschaftsüberprüfung) bei Datenzugriff
• Eingabevalidierung auf jedem Formular (server-seitig, nicht nur client-seitig)
• Datei-Upload-Limits (Größe und Typ), falls anwendbar
• Rate Limiting auf API-Endpoints
• Security-Headers konfiguriert
• npm audit ausgeführt und kritische Probleme behoben
• Custom Domain mit SSL konfiguriert
• Preview-Deployments geschützt
• Manueller Cross-Nutzer-Datenzugriff-Test bestanden

Das Fazit

Das Sichern einer Vibe-Coding-App geht nicht darum, ein Sicherheitsexperte zu werden. Es geht darum, eine Checkliste durchzuarbeiten, die die vorhersehbaren Lücken erfasst, die KI hinterlässt. Die obigen Schritte dauern 2–4 Stunden und verhindern die häufigsten Anfälligkeiten. Für eine Client-seitige App ist das nicht optional — es ist der Unterschied zwischen professioneller Arbeit und einer Haftung.

Wenn du deine erste Vibe-Coding-App erstellst, beginne mit unserem vollständigen Leitfaden zu Vibe Coding. Wenn du die Prompts verbessern möchtest, die du mit Claude oder Cursor nutzt, versuche unseren kostenlosen Prompt-Optimierer. Und für eine Zusammenfassung der besten Coding-Tools, siehe Claude Code vs Codex.

Offenlegung: Einige Links in diesem Artikel sind Affiliate-Links. Wir empfehlen nur Tools, die wir persönlich getestet haben und regelmäßig nutzen. Siehe unsere vollständige Offenlegungsrichtlinie.