Worum es geht
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?
Dieser Artikel zeigt, welche Schwachstellen bei einer systematischen Prüfung KI-generierter Apps immer wieder auftauchen — und wie du sie mit frei verfügbaren Scannern selbst findest.
Hinweis zu den Zahlen: Die Findings-Zahlen unten sind illustrative Größenordnungen, wie sie bei Scans vibe-gecodeter Apps typisch auftreten — keine Messreihe aus einem einzelnen kontrollierten Durchlauf. Führ die genannten Scanner gegen deinen eigenen generierten Code aus, um belastbare Zahlen für deine Tools und Prompts zu bekommen.
Ein realistisches Prüf-Setup
Wer den Effekt selbst nachvollziehen will, definiert eine Handvoll realistischer App-Typen, lässt sie von verschiedenen Tools generieren und jagt sie durch Scanner. Sinnvolle App-Typen für so eine Prüfung:
- Auth-Service (Register, Login, JWT-Refresh) — FastAPI plus Postgres
- Datei-Upload-API mit Virus-Scan — FastAPI plus ClamAV
- E-Commerce-Mini-Shop (Produkt-CRUD plus Warenkorb plus Checkout) — FastAPI
- Admin-Dashboard — Next.js plus Clerk-Auth
- Kontakt-Formular mit E-Mail-Versand — Next.js API-Route
- WebSocket-Chat-Service — FastAPI plus Redis
- Webhook-Empfänger für Stripe — Python
- CSV-Import-Endpoint mit Parsing — FastAPI
- User-Profile-API mit Avatar-Upload — Express.js
- Public-Share-Link-Service (Dokumente teilen) — FastAPI
Jede App grob 200-400 Zeilen Code, kein vollständiges Backend-System, aber realistische Workloads. Standardisierte Prompts, keine expliziten Security-Anweisungen — genau wie der durchschnittliche Vibe-Coder es macht. Als Tools bieten sich Cursor (mit Claude Sonnet als Backend), Claude Code direkt und v0.dev für UI-Sachen an.
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 — als Größenordnung
Die typische Verteilung, die so ein Scan produziert (illustrativ):
| Tool | Apps | High-Severity | Medium | Low | |---|---|---|---|---| | Cursor | 10 | ~7 | ~23 | ~41 | | Claude Code | 10 | ~3 | ~14 | ~29 | | v0.dev | 10 | ~11 | ~19 | ~27 |
Das Muster ist konsistenter als die exakten Zahlen: Backend-orientierte Tools mit viel Codebase-Kontext schneiden tendenziell besser ab; auf UI-Prototypen ausgelegte Tools (wie v0.dev) am schlechtesten, was plausibel ist — sie sind nicht für Backend-Security gebaut.
Aber auch das beste Tool produziert regelmäßig High-Severity-Lücken. Das ist keine kleine Zahl — und der eigentliche Punkt: Kein Vibe-Coding-Tool ist von sich aus sicher.
Die häufigsten Lücken
Hier wird's interessant. Die Muster, die immer wieder auftauchen:
SQL-Injection durch String-Interpolation
In Auth-Services taucht generierter Code auf, der so aussieht:
query = f"SELECT * FROM users WHERE email = '{email}' AND password = '{password}'"
cursor.execute(query)
Das ist SQL-Injection as a Service. Bessere Tools nutzen stattdessen korrekt Parametrisierung — aber verlassen kann man sich darauf nicht.
Fehlende Input-Validation bei Upload-Endpoints
Ein Großteil der Upload-Apps hat keine Größenbeschränkung, keinen MIME-Type-Check, keinen Scan. Du kannst eine 10-GB-Datei hochladen, eine .exe als Profilbild ablegen oder eine Zip-Bombe hochschicken. Das Muster ist fast universell.
Hardcoded Secrets
Tools schreiben gern API-Keys und DB-Passwörter als String in den Code — mit Kommentar "TODO: später als Env-Variable". Technisch kein Bug — aber wenn so ein Commit in ein öffentliches Repo geht, leaken die Credentials.
Session-Fixation in Auth-Services
Auth-Services ohne Session-Rotation nach Login sind häufig. Heißt: Ein Angreifer setzt vorher eine Session-ID, bewegt das Opfer zum Login und übernimmt dann die Session. Klassische Lücke, leicht zu fixen, wird von den Tools gern übersehen.
Keine Rate-Limits
Fast alle generierten Apps haben keine Rate-Limits auf Auth-Endpoints. Brute-Force wird damit trivial — einer der häufigsten echten Angriffe gegen Produktiv-Systeme, und die KI denkt einfach nicht dran.
CORS zu offen konfiguriert
Häufig allow_origins=["*"] — also jede beliebige Domain darf Requests schicken. In Produktion ein klares No-Go.
Der wichtigste Hebel — ein Satz im Prompt
Die aufschlussreichste Gegenprobe: dieselben Apps noch einmal generieren lassen, aber mit dem Zusatz im Prompt: "Achte auf OWASP-Top-10-Sicherheitslücken bei der Implementierung."
Das Ergebnis fällt typischerweise deutlich besser aus (illustrativ):
| Metrik | ohne Hint | mit Security-Hint | |---|---|---| | High-Findings | ~3 | ~0 | | Medium-Findings | ~14 | ~4 | | Low-Findings | ~29 | ~12 |
Die Lehre: Der Unterschied zwischen unsicherem 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:
Erstens: Security immer in den Prompt schreiben. Geh nicht davon aus, dass die KI "eh auf Sicherheit achtet". Schreib es rein, explizit. Jedes Prompt-Template sollte enthalten: "Achte auf OWASP-Top-10. Verwende Parametrisierung für DB-Queries. Setze Rate-Limits. Validiere User-Input." Kostet nichts, ändert messbar das Ergebnis.
Zweitens: Jeden Commit durch bandit/semgrep jagen. Als Pre-Commit-Hook. High-Severity-Findings blockieren den Commit. Fängt die groben Sachen automatisch ab, egal ob der Code von Mensch oder KI kommt.
Drittens: 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 gern 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. Authentication-Code liest man 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 in den nächsten Monaten.
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.
Der Rat an Firmen, die mit Vibe-Coding starten: Behandelt die KI wie einen Junior-Entwickler, der gern 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 allgemein die Pentesting-Säule.
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 für sichereren Code.
