Was in Cursor-, v0- und Lovable-generierten Apps in Production tatsächlich bricht

Zwischen „Prototyp funktioniert" und „das System hält echte Nutzer aus" liegt Arbeit, die keine KI-Coding-Plattform automatisiert. Cursor, v0, Lovable, Bolt und Replit Agent bauen in Tagen, was klassisch Wochen brauchen würde, aber sie bauen den Prototypen, nicht das Fundament. Für den Sprung in Production fehlen fast überall dieselben sieben Dinge.

Dieser Artikel fasst die Muster aus unserer Prüfungspraxis mit KI-generierten Webapps zusammen. Nahezu jedes bisher geprüfte System hatte mindestens vier der sieben Fehler; keines hatte weniger als drei. Das ist keine Kritik am Werkzeug, die Werkzeuge machen, wozu sie gebaut sind. Es ist eine Beobachtung, wo der Übergang vom MVP zur Production tatsächlich stattfindet.

Muster 1: Hardkodierte Zugangsdaten im Repository

Der häufigste Fund. In nahezu jeder Prüfung finden wir mindestens ein Secret direkt im Repo, API-Key eines LLM-Anbieters, Stripe-Test-Key, Supabase-Service-Role-Key, SMTP-Passwort. Die Hälfte davon lag zusätzlich in der Git-History aus dem ersten Commit, auch wenn das Secret später aus der Datei entfernt wurde, konnte es aus jedem Fork oder älteren Commit gelesen werden.

Der Grund ist strukturell: KI-Assistenten generieren funktionierenden Code am schnellsten, wenn Konfiguration inline steht. Der Founder sieht "es funktioniert" und schiebt weiter. .env.example wird oft gar nicht angelegt.

Was fehlt: eine strikte Trennung von Konfiguration und Code. .env in .gitignore, .env.example mit Platzhalter-Werten, im Deploy-System (Vercel, Netlify, Fly.io) als Environment-Variablen gepflegt. Wenn Secrets bereits in der Git-History waren: rotieren und Historie mit git filter-branch oder BFG-Repo-Cleaner bereinigen, Rotation allein reicht nicht, wenn das alte Secret noch in einem Fork liegt.

Muster 2: Auth-Endpunkte ohne Rate-Limit

In den meisten Prüfungen ließ sich der Login-Endpunkt beliebig oft aufrufen. Zwei der Apps akzeptierten 2.000+ Login-Versuche pro Minute pro IP; nach 2 Minuten Brute-Force gegen eine Test-E-Mail hatten wir Zugriff.

KI-Assistenten generieren Auth-Flows nach dem Muster ihrer Trainingsdaten, Login/Signup/Reset-Password. Rate-Limiting steht in denselben Trainingsdaten, aber nur wenn der Prompt explizit danach fragt. „Baue mir Auth mit Email/Password" ergibt selten Rate-Limits.

Was fehlt: ein Rate-Limit-Middleware auf allen Auth-Endpunkten, typisch 5 Versuche pro Minute pro IP für Login, 3 pro Stunde pro Email für Passwort-Reset. Für Next.js: @upstash/ratelimit mit Redis. Für Node/Express: express-rate-limit. Für Supabase: die eingebaute Auth-Rate-Limiting-Config aktivieren, die standardmäßig sehr großzügig ist.

Muster 3: Broken Object Level Authorization

Der teuerste Fund. In vielen der geprüften Apps konnten wir mit einem gültigen User-A-Token Ressourcen von User B abrufen, weil die API-Route die Berechtigungsprüfung vergaß. Typisches Muster: GET /api/invoice/[id] liefert die Rechnung zurück, ohne zu prüfen, ob die Rechnung dem eingeloggten Nutzer gehört.

Das ist bei KI-generierten APIs statistisch häufig, weil der Prompt „gib mir die Rechnung mit dieser ID" die Datenabfrage abbildet, aber die Autorisierung eine zweite, oft ungesagte Anforderung ist. Der KI-Assistent generiert die einfachere Variante.

Was fehlt: eine explizite Berechtigungsprüfung in jeder Route, die eine spezifische Ressource abfragt. Für Supabase: Row-Level-Security-Policies, die den auth.uid() gegen den user_id-Fremdschlüssel der Zeile prüfen. Für klassische Backends: Ein Middleware, der prüft, ob der eingeloggte Nutzer den Zugriff hat, mit Whitelist statt Blacklist.

Muster 4: npm-Pakete mit bekannten Sicherheitslücken

Regelmäßig finden wir Dutzende npm-Pakete pro Codebasis mit CVE-Alter größer 90 Tage, mehrere davon in high-severity-Kategorien.

Ursache: KI-Assistenten schlagen Pakete auf Basis ihrer Trainingsdaten vor, die möglicherweise 6–18 Monate alt sind. Der Founder nimmt den Vorschlag, npm install läuft, das Paket wird gepinnt und nie wieder angefasst.

Was fehlt: npm audit in der CI, dependabot oder renovate für automatische Update-PRs, und eine Policy „kein Merge in main mit unaufgelösten high-severity Findings". Zusätzlich: Package-Lock-Datei committen und im CI mit npm ci (nicht npm install) prüfen, damit Deploys reproduzierbar bleiben.

Muster 5: Fehlende serverseitige Input-Validierung

In den meisten Codebases war Input-Validierung nur im Frontend, mit Zod oder React Hook Form. Wer die API direkt aufruft (z.B. mit einer eigenen curl-Sequenz), umgeht die Validierung komplett.

KI-Assistenten generieren Frontend-Validierung, weil sie sichtbar ist, Nutzer sehen sofort, wenn ein Feld ungültig ist. Backend-Validierung ist unsichtbar und wird selten explizit angefragt.

Was fehlt: dieselbe Validierung im Backend wie im Frontend. Wenn Zod im Frontend läuft: dasselbe Schema server-seitig teilen (Shared-Types-Package oder Server-Actions in Next.js 14+, die Zod nativ unterstützen). Zusätzlich: strikte Ausgabekodierung, damit auch bei bösartiger Eingabe kein XSS entsteht, für React ist das eingebaut, für serverseitig gerenderten HTML muss manuell escaped werden.

Muster 6: Direktes DSGVO-Löschungs-Problem

In praktisch allen bisher geprüften Apps fehlt eine technische Umsetzung des Rechts auf Löschung nach Art. 17 DSGVO. Häufig ist das Löschen eines Nutzers technisch gar nicht möglich, ohne Datenbank-Integrität zu zerstören (Foreign Keys ohne Cascade-Regel). Wenn Löschen theoretisch möglich wäre, gibt es meist keinen UI-Pfad, keinen Support-Prozess und keine dokumentierten Backup-Retention-Regeln.

Das ist kein technischer Bug, es ist ein designter Bug. Die KI-Assistenten bauen Nutzer-Konten mit Signup und Login. Sie bauen nicht das Ende des Lebenszyklus.

Was fehlt: ein „Nutzer löschen"-Endpunkt, der alle personenbezogenen Daten des Nutzers löscht oder anonymisiert (je nach dokumentierter Rechtsgrundlage), ein UI-Element im Nutzer-Settings, ein Support-Prozess dahinter, und Backup-Retention, die dokumentiert ist. Die Löschung muss in dokumentierter Zeit erfolgen, typisch 30 Tage, in Ausnahmefällen mit Rechtsgrundlage länger.

Muster 7: Klartext-Logs mit sensiblen Daten

In sehr vielen Codebases finden wir Log-Einträge, die ein Passwort, einen API-Key oder eine E-Mail-Adresse im Klartext enthalten. Ursache: console.log(request.body) oder ähnliches im Debug-Mode, der im Deploy nicht deaktiviert wurde. Auf Vercel und Netlify sind diese Logs für einen bestimmten Zeitraum abrufbar; wer Zugriff auf das Dashboard hat, sieht die Daten.

Was fehlt: strukturiertes Logging mit Redaction-Regeln, z.B. mit pino und einem redact-Array für Felder wie password, token, email, authorization. Keine console.log(entireObject) in Production-Pfaden. Log-Retention dokumentieren; wer 30 Tage Zugriff auf Logs braucht, sagt es explizit, und die anderen Logs werden nach 7 Tagen gelöscht.

Was das für den Founder heißt

Diese sieben Muster sind nicht das Ergebnis schlechter Entwickler. Sie sind das Ergebnis von Werkzeugen, die einen anderen Zweck erfüllen, schnellen Prototyp, nicht produktive Auslieferung. Der Übergang zwischen den beiden Zielen ist keine Umbenennung von „MVP" zu „Production"; es ist echte Ingenieursarbeit.

Für den Founder, der aktuell einen KI-generierten Prototypen skalieren will, sind die praktischen Konsequenzen:

• Sofort: Zugangsdaten aus dem Repo raus, .env in .gitignore, alle Live-Secrets rotieren. Kostet zwei Stunden. Verhindert die häufigste Kategorie von Datenlecks.
• Diese Woche: Rate-Limits auf Auth-Endpunkten, RLS-Policies für alle sensiblen Tabellen, npm audit durchlaufen und die 10 kritischsten Findings fixen. Kostet ein bis zwei Tage.
• Diesen Monat: Nutzerkonto-Löschung, strukturiertes Logging, Backend-Validierung. Kostet drei bis fünf Tage.

Wer diese Reihenfolge einhält, hat 90 % der typischen Sicherheits- und DSGVO-Risiken behoben, bevor der erste echte Vorfall eintritt.

Nächster Schritt

Wir bauen für den beschriebenen Übergang ein 1-Tages-Audit, 30-Punkte-Checkliste, priorisierter Bericht mit fünf konkreten Fixes, €3.500 fix. Details unter https://cal.com/neuralmedic/audit-call.

Wenn Ihre App aktuell zwischen Prototyp und Production hängt: Kalender-Termin buchen, 30 Minuten, kostenlos, unverbindliche Einschätzung ob das Audit für Sie passt.

---

Verwandte Artikel: KI-generierte Webapps, die häufigsten DSGVO-Fallen · Vibe Coding zu Production: die Checkliste