Vibe Coding zu Production: Die vollständige Checkliste für den Übergang

Ein Prototyp mit Cursor, v0, Lovable oder Bolt zu bauen dauert Tage. Denselben Prototypen produktionsreif zu machen dauert Wochen. Nicht weil KI-Werkzeuge schlecht sind, sondern weil „produktionsreif" andere Anforderungen erfüllt als „funktioniert bei mir am Laptop".

Diese Checkliste ist der Prozess, den wir in unserer Prüfungspraxis anwenden, um KI-generierte Webapps in einen belastbaren Zustand zu bringen. Sechs Kategorien, dreißig Punkte, mit realistischer Aufwand­schätzung pro Punkt. Nicht alle sind für jeden Prototypen gleich relevant, aber die Reihenfolge stimmt für die meisten.

Kategorie 1: Zugangsdaten und Konfiguration (2 Stunden)

1.1 Alle Secrets aus dem Repository entfernen. Grep durchs Repo nach sk_, pk_, Bearer, password=, API_KEY. Was auch nur so aussieht wie ein Secret, wird raus. (30 Min)

1.2 .env.example mit Platzhaltern anlegen, .env in .gitignore verifizieren. Prüfen mit git check-ignore .env, muss den Dateinamen zurückliefern. (15 Min)

1.3 Alle jemals im Repo gewesenen Secrets rotieren. Auch die aus alten Commits. Ein Fork oder Clone hat sie noch. (60 Min bei 5–10 Secrets)

1.4 Git-History bereinigen wenn Secrets in Historie liegen. git filter-branch oder BFG Repo Cleaner. Danach force-push und alle Team-Mitglieder klonen neu. (30 Min bei kleinem Repo)

1.5 Deploy-System (Vercel/Netlify/Fly.io) Environment-Variablen prüfen. Alle Live-Secrets müssen dort und nur dort liegen. Zusätzlich: Zugriff auf das Dashboard auf wenige Personen beschränken, 2FA verpflichtend. (15 Min)

Kategorie 2: Authentifizierung und Session-Management (4 Stunden)

2.1 Rate-Limits auf allen Auth-Endpunkten. Login: 5/Minute pro IP. Passwort-Reset: 3/Stunde pro E-Mail. Signup: 3/Minute pro IP. Für Next.js: @upstash/ratelimit mit Redis. Für Supabase: eingebautes Auth-Rate-Limiting aktivieren. (60 Min)

2.2 Session-Cookies mit Secure, HttpOnly, SameSite=Lax. Bei Custom-Auth manuell setzen, bei Supabase/Clerk sind die Defaults meist okay, aber prüfen. (15 Min)

2.3 Passwort-Anforderungen im Backend prüfen. Minimum 10 Zeichen, HaveIBeenPwned-Prüfung bei Signup (kostenlose API von Troy Hunt). Frontend-only-Validierung reicht nicht. (60 Min)

2.4 2FA-Option anbieten. Für Founder-/Admin-Accounts verpflichtend, für User-Accounts optional. Über TOTP (Authenticator-Apps) oder Passkeys. (2 Stunden für Grund-Setup)

2.5 Logout löscht Session server-seitig. Nicht nur Cookie im Browser überschreiben, auch die Session in der Datenbank oder im Session-Store invalidieren. (30 Min)

Kategorie 3: Datenzugriff und Berechtigungen (6–8 Stunden)

3.1 Row-Level-Security auf allen sensiblen Tabellen. Bei Supabase: RLS-Policies für jede Tabelle mit personenbezogenen oder mandanten-bezogenen Daten. Bei klassischem Backend: Middleware, die den user_id-Fremdschlüssel gegen die Session prüft. (3 Stunden)

3.2 Direct Object References prüfen. Jede API-Route, die eine Ressource per ID abruft, muss Berechtigung prüfen. Grep durch die Routen nach [id], [slug], req.params.id und für jede prüfen, ob Autorisierung existiert. (2 Stunden)

3.3 SQL-Injection ausschließen. Kein String-Interpolation in Queries. ORM oder Parameter-gebundene Queries, je nach Stack Prisma, Drizzle, Kysely, oder pg mit Parameter-Arrays. Nicht mit KI-generierten String-Templates arbeiten. (1 Stunde audit + Fixes)

3.4 Für Multi-Mandanten: Tenant-Filter in jeder Query. Wenn Ihr System mehrere Kunden gleichzeitig bedient, muss jede Query einen WHERE tenant_id = ? haben. Am besten als Standard-Filter im ORM oder als RLS-Policy. (2 Stunden bei sauberer Struktur, länger bei Chaos)

3.5 API-Rate-Limits pro authentifiziertem Nutzer. Nicht nur pro IP, sonst kann ein Nutzer die ganze API monopolisieren. Typisch: 100 Requests/Minute pro Nutzer, 1000/Stunde. (30 Min)

Kategorie 4: Input-Validierung und Ausgabe­kodierung (3–4 Stunden)

4.1 Serverseitige Validierung für jeden Endpunkt. Zod, Yup, oder ähnliches, das Schema aus dem Frontend teilen. Bei Next.js 14+ Server Actions: Zod-Schemas nativ. Frontend-Validierung bleibt für UX, Backend-Validierung ist Sicherheit. (2 Stunden)

4.2 Ausgabekodierung bei benutzergeneriertem HTML. Wenn Sie irgendwo HTML-Ausgabe haben, die von Nutzer-Input abhängt (Kommentare, Profilseiten, dynamische Templates): DOMPurify, sanitize-html. Für React: dangerouslySetInnerHTML audit, jede Instanz prüfen. (1 Stunde)

4.3 CSRF-Schutz auf state-ändernden Endpunkten. Bei Next.js Server Actions: eingebaut. Bei Custom-APIs: Origin-Header prüfen, oder CSRF-Token in einem HttpOnly-Cookie plus Header. (30 Min)

4.4 File-Upload-Validierung. Dateityp per Magic-Bytes prüfen (nicht per Endung), Größenlimit, Antivirus wenn ausgeführt (ClamAV in einem Sidecar-Container), Speicherung außerhalb des Web-Root. (1 Stunde für Grund-Setup)

4.5 URL-Redirects auf Allowlist beschränken. Wenn Sie ?redirect= im Query-String verwenden (nach Login, nach Zahlung), gegen Allowlist prüfen. Sonst Open-Redirect-Schwachstelle. (15 Min)

Kategorie 5: DSGVO-Grundlagen (2–3 Tage)

5.1 Datenschutz­erklärung strukturiert nach Rechtsgrundlagen. Jede Kategorie personenbezogener Daten mit ihrer Art-6-Grundlage. Nicht alles unter „Vertragserfüllung". (3 Stunden mit Vorlage)

5.2 Recht auf Löschung technisch umgesetzt. DELETE /api/user/self-Endpunkt, im UI erreichbar, Foreign Keys mit Cascade-Regel oder Anonymisierung. Backup-Retention dokumentieren. (1 Tag bei mittlerer Datenmodell-Komplexität)

5.3 Recht auf Auskunft technisch bedienbar. Ein Export-Endpunkt, der alle personenbezogenen Daten eines Nutzers strukturiert (JSON, XML, CSV) zurückgibt. Nicht händisch, sondern automatisiert. (3 Stunden)

5.4 AV-Verträge mit allen externen Dienstleistern. Vercel, Supabase, Clerk, Stripe, OpenAI, jedes Analytics-Tool. Jeder Anbieter stellt Standard-DPA zur Verfügung, meist zum Download. Unterzeichnen und archivieren. (2 Stunden für ~8 Anbieter)

5.5 Cookie-Banner mit gleichwertigem Akzeptieren/Ablehnen. Erste Ebene: „Alle akzeptieren" und „Alle ablehnen" gleich prominent. Zweite Ebene: granulare Einstellung. Ohne Einwilligung keine nicht-notwendigen Cookies. Cookiebot, Usercentrics oder Klaro. (2 Stunden für Grund-Setup)

5.6 Meldeprozess nach Art. 33 dokumentieren. Einseitiges Dokument: Wer meldet, welche Behörde, welche Informationen. In den Griffbereich legen, nicht in ein vergessenes Notion-Verzeichnis. (1 Stunde)

Kategorie 6: Betrieb und Vorfallserkennung (1–2 Tage)

6.1 Strukturiertes Logging mit Redaction. pino oder winston mit redact-Array für sensible Felder (password, token, email, authorization). Keine console.log(request.body) in Production. (2 Stunden)

6.2 Log-Retention definiert. 7–30 Tage für die meisten Logs. Longer nur für dokumentierten Zweck. Nach Retention wirklich löschen. (30 Min)

6.3 Health-Check-Endpunkt. /api/health mit Datenbank-Verbindung, externem Service-Ping, Version. Für Uptime-Monitoring von Better Uptime, Pingdom oder UptimeRobot. (30 Min)

6.4 Error-Tracking mit Sentry oder ähnlich. Uncaught Exceptions, 500-Errors, ungewöhnliche Latenzen. Personenbezogene Daten redaction-fähig konfigurieren. (1 Stunde)

6.5 Backup-Test. Nicht nur Backups anlegen, mindestens einmal einen Restore in einer separaten Umgebung testen. Dokumentiert, mit Datum. (2 Stunden Setup, jährlich wiederholen)

6.6 Deployment-Rollback-Prozess. Wenn ein Deploy kaputtgeht, muss innerhalb von Minuten der vorherige Stand aktiv sein. Bei Vercel/Netlify eingebaut, bei eigenem Setup manuell definieren. (1 Stunde)

6.7 Alarme bei Anomalien. Login-Anomalien (viele fehlgeschlagene Versuche), Latenz-Spikes, Error-Raten-Anstiege. In Sentry oder Better Uptime als Rules. (2 Stunden)

Prioritätsempfehlung nach Zeit

Wenn Sie einen Tag haben: Kategorie 1 komplett, plus 2.1, 3.2, 5.5.

Wenn Sie eine Woche haben: Kategorien 1–3 komplett, plus 4.1, 5.1–5.4, 6.1.

Wenn Sie einen Monat haben: alle 30 Punkte, mit einem Puffer von etwa 20 % für Nachziehung, Diskussion und Edge-Cases.

Das Erste ist die minimal viable Absicherung. Das Zweite ist der Zustand, in dem Sie eine Kunden-Due-Diligence bestehen. Das Dritte ist der Zustand, in dem eine Aufsichtsbehörden-Anfrage strukturiert beantwortbar wäre.

Was diese Liste nicht abdeckt

Bewusst außen vor:

• Klassische Penetration-Tests. Diese Liste ist eine Audit-Vorbereitung, kein Ersatz. Wenn Ihre App sensiblere Daten verarbeitet (Gesundheit, Finanzen, biometrisch), planen Sie zusätzlich einen Pentest ab €8.000.
• ISO 27001 oder SOC 2. Diese Zertifikate haben Prozessanforderungen weit über technische Sicherheit hinaus. Bei Enterprise-B2B-Verkauf ab Series B relevant, für den Prototyp-zu-Production-Übergang nicht.
• Blockchain, End-to-End-Encryption, Zero-Knowledge-Proofs. Wenn Sie das brauchen, wissen Sie es. Wenn Sie nicht wissen, ob Sie es brauchen, brauchen Sie es nicht.

Nächster Schritt

Wenn Sie diese Liste selbst durchgehen wollen: das Dokument ist so aufgebaut, dass jeder Punkt in weniger als zwei Stunden abgearbeitet werden kann, mit einem senior Entwickler oder Founder, der schon einmal eine ähnliche Migration gemacht hat.

Wenn Sie es lieber outsourcen wollen, weil Sie an Ihrem eigentlichen Produkt arbeiten sollten: unser KI-Code-Audit prüft genau diese 30 Punkte in einem Tag, liefert einen schriftlichen Bericht mit priorisierten Fixes und kostet €3.500 fix.

Termin buchen, 30 Minuten, kostenlos, für die Einschätzung, ob das Audit für Sie passt.

---

Verwandte Artikel: Was in KI-generierten Apps in Production wirklich bricht · KI-generierte Webapps, die häufigsten DSGVO-Fallen