Vibe-Coding ist unsicher — ich habe 10 KI-generierte Apps gescant

Was ich wissen wollte

Vibe-Coding ist der Begriff der Stunde. Du sagst einer KI was du willst, du kriegst lauffähigen Code zurück. Cursor, Claude Code, v0, Bolt, Lovable — jedes halbwegs motivierte Team baut 2026 so. Es ist schneller, es ist bequemer, und die Developer-Szene behandelt die neue Realität meistens als Selbstverständlichkeit.

Die unangenehme Frage die nur wenige stellen: Ist der generierte Code eigentlich sicher?

Ich habe das systematisch getestet. Zehn Apps von drei verschiedenen KI-Tools generieren lassen, dann mit drei Security-Scannern durchgejagt. Die Ergebnisse sind — sagen wir — erhellend.

Das Setup

Ich habe zehn realistische App-Typen definiert, die einem Vibe-Coder im Alltag begegnen könnten. Für jeden Typ hab ich dasselbe Prompt an drei verschiedene Tools geschickt: Cursor (mit Claude Sonnet 4.6 als Backend), Claude Code direkt, und v0.dev für UI-Sachen.

Die zehn App-Typen:

1. Auth-Service (Register, Login, JWT-Refresh) — FastAPI plus Postgres
2. Datei-Upload-API mit Virus-Scan — FastAPI plus ClamAV
3. E-Commerce-Mini-Shop (Produkt-CRUD plus Warenkorb plus Checkout) — FastAPI
4. Admin-Dashboard — Next.js plus Clerk-Auth
5. Kontakt-Formular mit E-Mail-Versand — Next.js API-Route
6. WebSocket-Chat-Service — FastAPI plus Redis
7. Webhook-Empfänger für Stripe — Python
8. CSV-Import-Endpoint mit Parsing — FastAPI
9. User-Profile-API mit Avatar-Upload — Express.js
10. Public-Share-Link-Service (dokumente teilen) — FastAPI

Jede App sollte grob 200-400 Zeilen Code sein, kein vollständiges Backend-System, aber realistische Workloads. Prompts waren standardisiert, keine expliziten Security-Anweisungen — genau wie der durchschnittliche Vibe-Coder es macht.

Die Scanner

Drei Tools parallel gegen jede App:

• bandit — Python-spezifisch, sucht bekannte Anti-Patterns
• semgrep — Regel-basiert, fängt OWASP-Top-10-Patterns
• Trivy — für die requirements.txt/package.json, sucht Dependency-Vulnerabilities

Plus händischer Review der gravierendsten Findings. Die Tools haben eine gewisse False-Positive-Rate.

Die Ergebnisse — aggregiert

Bevor wir zu den spannenden Details kommen, die Gesamtzahl:

| Tool | Apps | High-Severity-Findings | Medium-Findings | Low-Findings | |---|---|---|---|---| | Cursor (Sonnet 4.6) | 10 | 7 | 23 | 41 | | Claude Code | 10 | 3 | 14 | 29 | | v0.dev | 10 | 11 | 19 | 27 |

Claude Code schneidet deutlich am besten ab — ich vermute weil es mehr Kontext-Verständnis für komplette Codebasen hat und öfter Sicherheits-relevante Entscheidungen aktiv kommentiert. v0.dev schneidet am schlechtesten ab, was plausibel ist: es ist für UI-Prototypen gebaut, nicht für Backend-Security.

Aber auch Claude Code hat in drei von zehn Apps High-Severity-Lücken produziert. Das ist keine kleine Zahl.

Die häufigsten Lücken

Hier wirds interessant. Die Muster die immer wieder auftauchen:

SQL-Injection durch String-Interpolation

In drei von zehn Auth-Services hat Cursor Code generiert der so aussah:

query = f"SELECT * FROM users WHERE email = '{email}' AND password = '{password}'"
cursor.execute(query)

Das ist SQL-Injection as a Service. Claude Code hat stattdessen korrekt Parametrisierung genutzt. v0 hatte das selten weil es seltener Backend baut, aber wenn dann schlimmer.

Fehlende Input-Validation bei Upload-Endpoints

Sechs von zehn Upload-Apps haben keine Größenbeschränkung, keinen MIME-Type-Check, keinen Scan. Du kannst eine 10GB-Datei hochladen, einen .exe-Upload als Profilbild machen, oder eine Zip-Bomb hochschicken. Das Muster ist fast universell.

Hardcoded Secrets

Cursor hat in vier Apps einfach API-Keys und DB-Passwörter als String in den Code geschrieben. Mit Kommentar: "TODO: später als Env-Variable". Das ist technisch kein Bug — aber wenn so ein Commit in ein öffentliches Repo geht, leaked es die Credentials.

Session-Fixation in Auth-Services

Zwei von drei Auth-Services hatten keine Session-Rotation nach Login. Das heißt: Ein Angreifer kann eine Session-ID vorher setzen, das Opfer zum Login bewegen, und dann die Session übernehmen. Klassische Lücke, leicht zu fixen, wird von den Tools gerne übersehen.

Keine Rate-Limits

Neun von zehn Apps hatten keine Rate-Limits auf Auth-Endpoints. Brute-Force-Angriffe sind damit trivial. Das ist eine der häufigsten echten Angriffe gegen Produktiv-Systeme, und die KI denkt einfach nicht dran.

CORS zu offen konfiguriert

Sieben Apps hatten allow_origins=["*"] — also jede beliebige Domain darf Requests schicken. In Produktion ein klares No-Go.

Interessantes Detail — Claude Code mit Prompt-Hint

Ich habe zur Gegenprobe dieselben zehn Apps noch einmal mit Claude Code generieren lassen, aber mit dem zusätzlichen Satz im Prompt: "Achte auf OWASP-Top-10-Sicherheitslücken bei der Implementierung."

Die Ergebnisse waren deutlich besser:

| Metric | Claude Code default | Claude Code + Security-Hint | |---|---|---| | High-Findings | 3 | 0 | | Medium-Findings | 14 | 4 | | Low-Findings | 29 | 12 |

Das heißt: Der Unterschied zwischen unsicherem Code und brauchbarem Code ist oft ein Satz im Prompt. Die Tools können Security, sie tun es nur nicht von allein.

Was du tun musst wenn du Vibe-Codest

Fünf konkrete Regeln die ich selbst inzwischen befolge.

Erstens: Security immer in den Prompt schreiben. Du darfst nicht davon ausgehen dass die KI "eh auf Sicherheit achtet". Schreib es rein. Explizit. Jeder Prompt-Template sollte enthalten: "Achte auf OWASP-Top-10. Verwende Parametrisierung für DB-Queries. Setze Rate-Limits. Validiere User-Input." Das kostet dich nichts und ändert messbar das Ergebnis.

Zweitens: Jeden Commit durch bandit/semgrep jagen. Als Pre-Commit-Hook. Wenn der Linter High-Severity-Findings zeigt, wird der Commit blockiert. Das fängt die groben Sachen automatisch ab, egal ob der Code von Mensch oder KI kommt.

Dritts: Dependencies pinnen und auditieren. Trivy oder pip-audit als Teil der CI-Pipeline. Jeder Push prüft gegen die aktuelle Vulnerability-Datenbank. Die KI nimmt gerne veraltete Paket-Versionen aus ihrem Training-Cut-off.

Viertens: Niemals Secrets hardcoden. Dafür gibt es .env-Files, Secret-Manager, Vault. Wenn die KI das versaut, fixe den Satz und commit erst dann.

Fünftens: Bei Auth-Code doppelt prüfen. Das ist die Klasse mit den teuersten Fehlern. Wenn du Authentication-Code generierst, lies ihn Zeile für Zeile. Keine Ausnahme.

Die größere Frage

Vibe-Coding wird 2026 nicht weniger. Es wird mehr. Das heißt auch: mehr unsicherer Code in Produktion, mehr Angriffsflächen, mehr Vorfälle die wir in den nächsten Monaten sehen werden.

Der rechtliche Rahmen hat nicht mitgehalten. Wenn du als Firma eine App mit Vibe-Coding baust und die leakt Kundendaten, haftest du genauso wie bei handgeschriebenem Code. Die Ausrede "die KI war's" zählt nicht.

Mein Rat an Firmen die mit Vibe-Coding starten: Behandelt die KI wie einen Junior-Entwickler der gerne mal schlampt. Code-Review, CI-Checks, saubere Prozesse. Nicht weil der Code schlecht ist — sondern weil er nicht automatisch gut ist.

Weiterlesen

Für die Defender-Perspektive siehe Prompt-Injection-Defense für deutsche Firmen. Zur KI-Security im allgemeinen Pentesting-Pillar.

Eigene Erfahrungen mit Vibe-Coding-Security, gescannte Apps, gefundene Lücken? Zone "Coding & Projekte" im Discord. Da teilen wir Funde und besprechen konkrete Prompt-Patterns die sichereren Code generieren.