Vibecoding ist schnell. Du beschreibst, was du willst, die KI baut es, und du shippst. Aber jedes Feature, das du hinzufügst, ohne die Sicherheitsimplikationen zu prüfen, ist eine Tür, die du vergessen hast abzuschliessen.
Die meisten vibgecodeten Apps haben dieselben Schwachstellen - fehlende Auth-Checks, geleakte Fehlermeldungen, Race Conditions bei Zahlungsflüssen, nicht-sanitisierte Datei-Uploads. Nicht weil die KI schlecht in Sicherheit ist, sondern weil niemand sie gebeten hat, an Sicherheit zu denken.
Ein Prompt ändert das.
Die Prompts
Hier sind drei Prompts, je nachdem wie tief du gehen willst. Starte mit dem ersten, wenn du deine App noch nie geprüft hast. Nutze den zweiten für einen gezielten Deep Dive. Nutze den dritten, um Sicherheit in deinen regulären Workflow einzubauen.
Prompt 1 - Vollständiges Audit (empfohlen für das erste Mal)
Do a complete security audit of my app like a professional whitehat hacker. Use plan mode.
Cover these areas:
- Authentication and authorization (missing auth checks, session handling, privilege escalation)
- API route security (input validation, rate limiting, error message leaks)
- Injection vulnerabilities (XSS, SVG injection, SQL injection, command injection)
- File upload security (type validation, size limits, malicious content)
- Payment and billing logic (race conditions, webhook verification, credit bypass)
- Dependencies (npm audit, known CVEs)
- Security headers (CSP, HSTS, X-Frame-Options)
- Secrets management (hardcoded keys, env variable exposure)
For every finding: state the severity, the exact file and line number, the attack scenario, and the fix.
Prioritize by severity. Then fix everything, starting with critical issues.
Prompt 2 - Gezielter Deep Dive
Act as a penetration tester. Focus specifically on race conditions and business logic flaws in my app.
Look for:
- TOCTOU (time-of-check-time-of-use) bugs in credit systems, usage limits, and payment flows
- Check-then-act patterns where concurrent requests can bypass limits
- Endpoints where the check and the action happen in separate API calls
- Webhook handlers that are not idempotent
- Any read-then-write pattern without database-level locking
For each finding, show me a concrete attack scenario with parallel requests and provide an atomic fix.
Prompt 3 - Schneller Pre-Deploy-Check
I am about to deploy. Do a quick security sanity check:
1. Run npm audit and summarize high/critical vulnerabilities
2. Check all API routes for missing authentication
3. Check for any error responses that leak internal details (error.message, stack traces)
4. Verify rate limiting exists on all public-facing endpoints
5. Check that no secrets are hardcoded or exposed via NEXT_PUBLIC_ prefixed env vars
6. Check file uploads for missing type/size validation
Keep it concise. Flag only real issues, not theoretical concerns.
Warum Plan-Modus wichtig ist
Wenn du den Plan-Modus aktivierst, fängt Claude Code nicht sofort an, Dateien zu ändern. Es liest zuerst. Es durchsucht deine Codebase mit mehreren parallelen Agenten, kartiert die Architektur, identifiziert jede relevante Datei und präsentiert dir dann einen strukturierten Plan, bevor irgendetwas angefasst wird.
Das ist für Sicherheit wichtig, weil:
- Du siehst das Gesamtbild, bevor irgendwelche Änderungen passieren. Ein Sicherheitsaudit, das still im Hintergrund Dateien editiert, ist riskant - du willst sehen, was gefunden wurde, und genehmigen, was gefixt wird.
- Die KI geht tiefer. Im Plan-Modus startet sie dedizierte Explorations-Agenten, die deine gesamte Codebase gleichzeitig durchsuchen. Ein Agent prüft Auth, ein anderer prüft API-Routen, ein dritter prüft Dependencies. Das ist gründlicher als eine lineare Konversation.
- Du behältst die Kontrolle. Du genehmigst den Plan, dann führt die KI ihn aus. Wenn ein Finding ein False Positive oder eine Design-Entscheidung ist, kannst du es überspringen, bevor Code geändert wird.
Um den Plan-Modus zu aktivieren, tippe /plan in Claude Code, bevor du deinen Prompt sendest. Oder füge "Use plan mode" zum Prompt selbst hinzu.
Der Iterations-Workflow
Ein Sicherheitsaudit ist kein einmaliger Fix. Manche Änderungen brechen Dinge. Manche Fixes decken neue Probleme auf. Hier ist der Workflow, der tatsächlich funktioniert:
Schritt 1 - Audit im Plan-Modus starten. Lass Claude erkunden und Findings präsentieren. Prüfe sie.
Schritt 2 - Genehmigen und fixen lassen. Verlasse den Plan-Modus, damit Claude die Fixes implementiert.
Schritt 3 - Dev-Server starten und testen.
npm run dev
Öffne http://localhost:3000 in deinem Browser. Klicke dich durch die App. Teste die Flows, die gemeldet wurden - Login, Datei-Uploads, Zahlung, API-Aufrufe. Stell sicher, dass nichts kaputt ist.
Schritt 4 - Nächste Runde starten. Sobald localhost gut aussieht, sag Claude:
Do another security pass. Focus on what we might have missed - race conditions, business logic, edge cases. Think like an attacker.
Diese zweite Runde findet die tieferen Probleme, die erst auftauchen, nachdem die offensichtlichen Schwachstellen gepatcht sind.
Schritt 5 - Bauen und verifizieren.
npm run build
Ein sauberer Build ohne TypeScript-Fehler bestätigt, dass strukturell nichts kaputt ist.
Wiederhole Schritte 3 bis 5, bis du zufrieden bist. Zwei bis drei Runden decken normalerweise alles ab.
Die häufigsten Schwachstellen in vibgecodeten Apps
Nach dem Audit mehrerer mit KI gebauter Apps tauchen dieselben Muster immer wieder auf. Wenn du vibest, prüfe zuerst diese.
Fehlende Autorisierungs-Checks
Die KI baut einen funktionierenden Endpoint, vergisst aber zu prüfen, ob User A auf die Daten von User B zugreifen kann. Ein Delete-Endpoint, der einen ID-Parameter nimmt, aber keine Ownership prüft, ist die häufigste Version davon.
Worauf du achten solltest: Jede API-Route, die eine ID aus dem Request akzeptiert. Filtert sie nach der ID des authentifizierten Users?
Fehlermeldungen, die Internas leaken
Wenn etwas fehlschlägt, gibt die API den rohen Datenbankfehler an den Client zurück. Das legt Tabellennamen, Spaltennamen und manchmal die Query-Struktur offen.
Worauf du achten solltest: Jedes error.message, das in einer JSON-Response zurückgegeben wird. Ersetze es mit einer generischen Nachricht und logge die Details serverseitig.
Race Conditions bei Credits und Limits
Ein Usage-Check und ein Usage-Increment passieren in zwei separaten API-Calls. Zwischen dem Check und dem Increment passieren fünf parallele Requests alle den Check. Der User sprengt sein Limit.
Worauf du achten solltest: Jedes Muster, wo du einen Counter liest, prüfst und dann in einem separaten Call schreibst. Diese müssen in eine einzige atomare Datenbankoperation mit Row Locking kombiniert werden.
Nicht-sanitisierte Datei-Uploads
SVG-Dateien können JavaScript enthalten. Bild-Uploads vertrauen dem MIME-Type-Header, statt die tatsächlichen Datei-Bytes zu prüfen. Es gibt kein Grössenlimit oder gar keine serverseitige Validierung.
Worauf du achten solltest: Jeder Datei-Upload-Endpoint. Validiert er den Dateityp anhand des Inhalts (Magic Bytes), nicht nur des Headers? Erzwingt er ein Grössenlimit? Wenn er SVGs akzeptiert, sanitisiert er sie?
Secrets im Client-Code
Umgebungsvariablen mit dem Präfix NEXT_PUBLIC_ werden in den Browser gebündelt. Ein Dev-Bypass-Flag oder ein API-Key mit diesem Präfix ist für jeden sichtbar, der die Browser-Devtools öffnet.
Worauf du achten solltest: Jede NEXT_PUBLIC_-Variable. Ist sie sicher öffentlich? Service-Role-Keys, Webhook-Secrets und Dev-only-Flags sollten dieses Präfix nie haben.
Verwundbare Dependencies
Die App wird mit bekannten CVEs im Dependency-Tree ausgeliefert, weil niemand npm audit ausgeführt hat. Einige davon haben hohe Severity mit veröffentlichten Exploits.
Worauf du achten solltest: Führe npm audit jetzt sofort aus. Fixe, was du mit npm audit fix kannst. Den Rest manuell prüfen.
Kein Rate Limiting
Jeder öffentliche Endpoint kann tausende Male pro Sekunde aufgerufen werden. Signup, Login, Datei-Upload, Zahlung - alles ungeschützt. Das ermöglicht Brute-Force-Angriffe, Spam und Resource Exhaustion.
Worauf du achten solltest: Hat jeder Endpoint, der User-Input akzeptiert, ein Rate Limit? Nutze IP-basierte Limits für öffentliche Routen und User-basierte Limits für authentifizierte Routen.
Mach es zur Gewohnheit
Sicherheit ist nichts, was du einmal machst und vergisst. Jedes neue Feature führt neue Angriffsfläche ein. Hier ist ein einfacher Rhythmus:
- Vor jedem Deploy - Starte Prompt 3 (der schnelle Sanity-Check). Dauert zwei Minuten.
- Alle zwei Wochen - Starte Prompt 1 (das vollständige Audit). Findings prüfen, fixen was wichtig ist.
- Nach grossen Features - Starte Prompt 2 (der gezielte Deep Dive) auf den Bereich, den du gerade gebaut hast.
Das gesamte Audit ist kostenlos, wenn du Claude Code bereits nutzt. Es gibt keinen Grund, es nicht zu tun.
Los geht's
Kopiere Prompt 1 oben, wechsle in den Plan-Modus und füge ihn ein. Prüfe die Findings. Genehmige den Plan. Teste auf Localhost. Iteriere. Deine App wird in einer einzigen Session spürbar sicherer.