Wie man eine Vibe-Coded App vor der Übergabe an Kunden sichert

Wenn du eine App mit Claude oder Cursor vibe-codiert hast und sie gerade an einen zahlenden Kunden übergeben willst, halt an. Von KI generierter Code enthält vorhersehbare Sicherheitslücken — offengelegte API-Schlüssel, fehlende Eingabevalidierung, Standard-Datenbankberechtigungen, die es jedem Benutzer ermöglichen, die Daten aller anderen zu sehen. Das sind keine Grenzfälle. Sie treten in fast jedem ersten Durchlauf einer KI-generierten Codebasis auf.

Dieser Leitfaden ist deine Sicherheitsprüfliste vor dem Launch. Befolge ihn Schritt für Schritt, bevor ein echter Benutzer deine App anfasst. Er ist für den häufigsten Vibe-Coding-Stack geschrieben (Next.js + Supabase + Vercel), aber die Prinzipien gelten unabhängig von deinen Tools.

Warum von 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", generiert es Code, der Benutzer erstellt, Aufgaben speichert und anzeigt. Was es wahrscheinlich nicht automatisch tun wird: sicherstellen, dass Benutzer A die Aufgaben von Benutzer B nicht sehen kann, validieren, dass Eingabefelder keine bösartigen Skripte akzeptieren, deine API-Schlüssel vor den Browser-Entwicklungstools verbergen oder Rate Limiting hinzufügen, um zu verhindern, dass jemand deine Endpoints bombardiert.

Das sind keine Ausfälle der KI — das sind Lücken in der Eingabeaufforderung. Die KI baut, worum du gebeten hast. Du hast wahrscheinlich nicht um Sicherheit gebeten, weil du dich auf Features konzentriert hast. Jetzt ist es an der Zeit, zurückzugehen und sie hinzuzufügen.

Schritt 1: Überprüfe deine Umgebungsvariablen

Das ist der häufigste und gefährlichste Fehler in vibe-codierten Apps. Überprüfe jede Datei in deinem Projekt auf hartcodierte API-Schlüssel, Datenbank-URLs oder Geheimnisse.

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 speziell: jede Datei in deinem /app oder /pages Verzeichnis, jede Komponentendatei, deine next.config.js und alle Utility-Dateien.

Die Lösung: Verschiebe jedes Geheimnis in Umgebungsvariablen. In Next.js werden nur Variablen mit dem Präfix NEXT_PUBLIC_ im Browser verfügbar gemacht. Deine Datenbank-URL, dein Service-Role-Key und deine 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 im Browser verfügbar zu machen:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Überprüfe: Schau in deine .gitignore Datei, ob sie .env.local enthält. Falls du bereits Geheimnisse in Git committed hast, sind sie in deiner Historie — selbst nach dem Löschen — rotiere (regeneriere) sofort jeden exponierten Schlüssel.

Schritt 2: Aktiviere Row-Level Security in Supabase

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

Die Lösung: Aktiviere Row-Level Security (RLS) für jede Tabelle und erstelle dann Richtlinien, die den Zugriff beschränken.

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

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

Teste es: Melde dich als Benutzer A an und versuche, über die API auf die Daten von Benutzer B 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-Queries mit dem service_role Key (der RLS umgeht) anstelle des anon Keys mit geeigneten RLS-Richtlinien. Überprüfe, dass dein clientseitiger Code nur den Anon-Key verwendet. Der Service-Role-Key sollte nur im serverseitigen Code (API-Routes, Server Actions) existieren und niemals im Browser verfügbar sein.

Schritt 3: Füge Authentifizierung richtig hinzu

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

Sitzungsverwaltung: Stelle sicher, dass Sitzungen ablaufen. Überprüfe, dass dein Auth-Setup ein angemessenes Sitzungs-Timeout beinhaltet (Supabase-Standards sind in der Regel gut, aber überprüfe es). Stelle sicher, dass sich Abmelden tatsächlich die Sitzung ungültig macht, nicht nur das lokale Cookie löscht.

Passwortanforderungen: Falls du Email/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 anzeigt, benötigt Authentifizierungs-Middleware. In Next.js App Router erstelle eine Middleware, die auf eine gültige Sitzung überprüft und nicht authentifizierte Benutzer zur Anmeldeseite umleitet. Verlasse dich nicht nur auf clientseitige Überprüfungen — ein Benutzer kann diese umgehen, indem er deine API direkt aufruft.

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

Schritt 4: Validiere alle Eingaben

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

Was du hinzufügen solltest:

Serverseitige Validierung auf jedem API-Endpoint. Vertraue niemals nur auf clientseitige Validierung — sie kann umgangen werden, indem Anfragen direkt an deine API gesendet werden. Verwende eine Validierungsbibliothek wie Zod (für TypeScript), um Schemas für jedes Datenelement zu definieren, das deine App akzeptiert.

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

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

Schritt 5: Sichere deine API-Routes

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

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

Autorisierung über Authentifizierung hinaus. Auch nach Bestätigung, dass ein Benutzer angemeldet ist, überprüfe, dass er die spezifische Ressource, die er anfordert, zugreifen darf. „Benutzer A ist angemeldet" bedeutet nicht „Benutzer A kann Benutzer B's Profil bearbeiten". Überprüfe die Eigentümerschaft auf jedem Datenzugriff.

Rate Limiting. Ohne Rate Limiting kann jemand tausende Anfragen pro Sekunde an deine API senden, um entweder Daten zu scrapen oder deinen Server zu überlasten. Füge grundlegendes Rate Limiting mit einer Bibliothek wie rate-limiter-flexible hinzu oder verwende Vercels eingebautes Rate Limiting für Edge Functions.

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

Schritt 6: Überprüfe deine Deployment-Konfiguration

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

Zu überprüfende Vercel-Einstellungen: Aktiviere „Deployment Protection" (benötigt Auth, um Preview-Deployments anzusehen — verhindert, dass Clients versehentlich Preview-URLs freigeben, die In-Progress-Arbeit exposieren). Richte Ausgabenlimits ein, um unerwartete Gebühren zu verhindern, wenn deine App Traffic-Spitzen erhält. Konfiguriere deine zulässigen Domains in CORS-Headers.

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

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

Schritt 7: Führe einen finalen Security-Scan durch

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

npm audit: Führe npm audit in deinem Projektverzeichnis aus. Es markiert bekannte Anfälligkeiten in deinen Abhängigkeiten. Behebe kritische und hochgradige Probleme. Führe npm audit fix für automatische Korrektionen aus, wo verfügbar.

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

Manuelles Testen: Melde dich als ein Benutzer an und versuche, über geänderte URLs oder API-Aufrufe auf die Daten eines anderen Benutzers zuzugreifen. Versuche, leere Formulare, übergroße Eingaben und Sonderzeichen (wie codierte XSS-Payloads) einzureichen. Falls einer davon funktioniert, hast du Probleme zu beheben.

Die Checkliste vor dem Launch

Drucke das aus und überprüfe jeden Punkt, bevor du live gehst:

• Alle Geheimnisse in Umgebungsvariablen (keine hartcodierten Schlüssel)
• .env.local in .gitignore (und keine Geheimnisse in Git-Historie)
• Supabase RLS auf jeder Tabelle aktiviert
• RLS-Richtlinien getestet (Benutzer A kann die Daten von Benutzer B nicht sehen)
• Clientseitiger Code verwendet nur Anon-Key (Service-Role-Key nur serverseitig)
• Authentifizierung auf jedem API-Route
• Autorisierungsüberprüfungen (Eigentümerschaftsverifizierung) auf Datenzugriff
• Eingabevalidierung auf jedem Formular (serverseitig, nicht nur clientseitig)
• Dateiupload-Limits (Größe und Typ), falls zutreffend
• 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
• Test für manuelle Cross-User-Datenzugriffstest bestanden

Das Endergebnis

Das Sichern einer vibe-codierten App ist nicht davon abhängig, ein Sicherheitsexperte zu werden. Es ist davon abhängig, eine Checkliste durchzulaufen, die die vorhersehbaren Lücken fängt, die KI hinterlässt. Die obigen Schritte dauern 2–4 Stunden und verhindern die häufigsten Anfälligkeiten. Für eine kundenorientierte App ist dies nicht optional — es ist der Unterschied zwischen professioneller Arbeit und einer Haftung.

Falls du deine erste vibe-codierte App baust, starten mit unserem kompletten Leitfaden zum Vibe Coding. Falls du die Prompts, die du mit Claude oder Cursor verwendest, verbessern möchtest, versuche unseren kostenlosen Prompt-Optimierer. Und für eine Übersicht 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 verwenden. Siehe unsere vollständige Offenlegungsrichtlinie.