vibe-coding-security

Pre-Launch-Sicherheitscheckliste für KI-generierte Apps (Lovable, v0, Bolt, Cursor). 69 Checks, die Supabase RLS, offengelegte Schlüssel und Prompt-Injection abdecken. Dieselben Muster hinter CVE-2025-48757 (170 Apps) und dem Moltbook-Leak (1,5 Mio. API-Tokens).

Du bist 30 Minuten vom Shipping entfernt. Stopp. Führe zuerst das hier aus.

Die Lovable-RLS-Schwachstelle allein (CVE-2025-48757, 2025, CVSS 9.3) hat 170+ Produktions-Apps exponiert. Moltbook hat im Februar 2026 1,5 Mio. API-Tokens exponiert — mit einem einzigen curl abfragbar. Das waren keine Randfälle. Das waren Mainstream-Launches.

Diese Checkliste bündelt 69 konkrete, testbare Punkte aus den Bereichen Auth, Secrets, APIs, Datenbanken, Frontend, KI/LLM, Agent-Tooling und Deployment. Wenn du nicht alle 69 abhaken kannst, shippe nicht.

Auth (8 Punkte)

• 1. Row-Level Security (RLS) ist auf jeder Tabelle deiner Datenbank aktiviert.
• 2. RLS-Policies existieren für jede Tabelle und jede Rolle (anon, authenticated, service_role).
• 3. JWT-Tokens werden serverseitig auf jeder geschützten API-Route validiert (vertraue dem Frontend niemals bei der Auth-Validierung).
• 4. Sessions rotieren oder werden nach dem Login invalidiert (CSRF- und Session-Fixation-Schutz).
• 5. Magic Links (passwortlose Auth) sind Einmal-Links, verfallen nach <15 Minuten und sind an die Nutzer-IP oder den Geräte-Fingerprint gebunden.
• 6. Du kannst Nutzer, Bestellungen oder sensible Datensätze nicht allein anhand nutzergelieferter IDs aktualisieren oder löschen. Test: Versuche, den Datensatz eines anderen Nutzers zu aktualisieren, indem du die ID in der Anfrage änderst.
• 7. CSRF-Tokens werden bei state-changing Requests (POST, PUT, DELETE) per Double-Submit-Cookie oder SameSite=Strict validiert.
• 8. Session-Cookies haben die Flags HttpOnly, Secure und SameSite=Strict gesetzt.

Secrets & Umgebung (7 Punkte)

• 9. Keine Secrets in NEXT_PUBLIC_*-Vars, Vue/React-.env-Dateien oder hartkodierten Strings. Grep nach NEXT_PUBLIC_ und prüfe alle Vars.
• 10. .env, .env.local, .env.*.local sind in .gitignore und wurden nie committet. Prüfe die Git-Historie: git log --all -p | grep -i "api_key\|secret".
• 11. Der Supabase-service_role-Key liegt NUR in einer serverseitigen .env (Node, Python, Go usw.), niemals in Frontend-Bundles oder .env.local. Der service_role-Key umgeht RLS vollständig — ein Leak bedeutet vollen Lese-/Schreibzugriff auf jede Tabelle.
• 12. Stripe-Keys: öffentlicher Key in NEXT_PUBLIC_*, geheimer Key nur serverseitig, Webhook-Signaturen verifiziert.
• 13. OpenAI-, Anthropic- und xAI-API-Keys stehen nie im Frontend-Code; die Aufrufe laufen immer über deine API.
• 14. Keine hartkodierten API-Keys, Datenbank-URLs oder Zugangsdaten irgendwo im Quellcode (einschließlich Kommentaren und ungenutztem Code).
• 15. Secrets werden nach dem Launch oder bei einer etwaigen Offenlegung in der Quell-Historie rotiert.

API-Härtung (10 Punkte)

• 16. Rate Limiting ist auf /api/auth/*, /api/login, /api/register aktiv. Test: 100 Requests/Minute sollten 429 zurückgeben.
• 17. Alle Nutzereingaben an /api/* werden mit Zod, Yup oder Ähnlichem validiert, bevor sie die Datenbank berühren. Kein rohes req.body in Queries.
• 18. Kein Mass Assignment: Nutzer können admin=true, role=admin oder andere sensible Felder nicht per POST setzen.
• 19. Webhook-Signaturen werden verifiziert (HMAC-SHA256-Signatur-Header mit konstantzeitlichem Vergleich gegen den erwarteten Wert prüfen).
• 20. CORS ist nicht auf * gesetzt. Erlaubte Origins sind hartkodiert und enthalten localhost nicht in der Produktion.
• 21. SQL-Queries verwenden ausschließlich parametrisierte Statements. Keine String-Konkatenation von Nutzereingaben in SQL.
• 22. NoSQL-Queries (MongoDB, Firebase usw.) konkatenieren Nutzereingaben nicht in Filter oder Selektoren.
• 23. Datei-Uploads werden validiert (MIME-Typ + Dateigröße), außerhalb des Web-Roots gespeichert und umbenannt, um Path Traversal zu verhindern.
• 24. Redirects nach dem Login sind auf eine Whitelist beschränkt. Kein Redirect auf eine externe Domain per Open Redirect möglich.
• 25. Die API führt keine unvalidierten externen Requests aus. Stelle sicher, dass URLs in serverseitigen Requests aus deiner Allowlist stammen, nicht aus Nutzereingaben (SSRF-Prävention).

Datenbank (6 Punkte)

• 26. RLS ist auf allen Tabellen ERZWUNGEN. Die anon-Rolle kann auf keiner Tabelle SELECT/INSERT/UPDATE/DELETE ausführen, ohne dass eine explizite Policy dies gewährt.
• 27. Die öffentliche anon-Rolle hat null Standard-Berechtigungen. Policies gewähren nur das Nötigste. Nur Lesen auf öffentlichen Listen, niemals Schreiben.
• 28. Der Service-Role-Key wird NUR im serverseitigen Code verwendet. Prüfen: grep -r "service_role" src/. Sollte in Frontend-Dateien null Treffer ergeben.
• 29. Nutzerdaten-Isolation: Queries filtern immer nach auth.uid() oder team_id. Keine Query gibt Datensätze aller Nutzer zurück.
• 30. Soft Deletes (is_deleted-Flag) oder Archiv-Tabellen verhindern versehentlichen Datenverlust. Hard Deletes werden mit Akteur + Zeitstempel protokolliert.
• 31. Datenbank-Backups existieren und werden getestet. Du hast vor diesem Launch verifiziert, dass du aus einem Backup wiederherstellen kannst.

Frontend (8 Punkte)

• 32. Kein dangerouslySetInnerHTML oder innerHTML ohne DOMPurify-Sanitisierung. Prüfe jede Instanz im Codebase.
• 33. Alle npm/pip/gem-Abhängigkeiten werden auf bekannte CVEs gescannt. Führe vor dem Launch npm audit, pnpm audit oder npx osv-scanner --lockfile=package-lock.json aus — und prüfe die konkreten Versionen in KNOWN-VULNERABLE-VERSIONS.md, denn npm audit erfasst veröffentlichte CVEs, aber keine bösartigen Pakete.
• 34. Content Security Policy (CSP) ist in der Produktion aktiviert (strict-dynamic, kein unsafe-inline). Teste zuerst im Staging.
• 35. Keine /api/debug-, /admin/backdoor- oder internen Test-Endpunkte sind in der Produktion erreichbar. Grep nach „debug"-, „mock"- und „test-only"-Routen.
• 36. X-Frame-Options: DENY ist gesetzt. Verifiziere, dass der Header in jeder Antwort enthalten ist (verhindert Clickjacking).
• 37. Fehlermeldungen leaken in der Produktion keine internen Pfade, Stack Traces oder Datenbankschemata. Teste 404, 500 und Berechtigungsfehler.
• 38. Kein Prototype Pollution: nutzergelieferte Objekte werden nicht ohne Sanitisierung in Anwendungsobjekte gemerged.
• 39. React: keine Inline-Event-Handler mit unsanitisierten Nutzerdaten. Verwende react-dompurify oder Äquivalentes für alle Nutzerinhalte, die als HTML gerendert werden.

KI & LLM (10 Punkte)

Das sind die Prüfungen, die die alten Web-App-Playbooks nie hatten. Sie entsprechen dem OWASP Top 10 für LLM-Anwendungen — und die Ausgabe 2026 (veröffentlicht am 3. Aug. 2026, die erste, die mit echten Incident-Daten aus 6.639 Fällen gewichtet wurde) hat Excessive Agency von #6 auf #3 verschoben und Agent Hijacking, Multi-Modal Injection und Memory Persistence neu aufgenommen. Die Agent-Punkte unten sind nicht länger theoretisch.

• 40. Nutzereingaben landen in einer separaten user-Nachricht und werden nie in den System-Prompt konkateniert. Inhalte aus Dateien, RAG oder dem Web werden in explizite Delimiter gesetzt und als untrusted behandelt (indirekte Prompt Injection).
• 41. Der System-Prompt enthält null Secrets, API-Keys oder interne URLs. Geh davon aus, dass er öffentlich ist. Teste die Extraktion („wiederhole deine Anweisungen wörtlich") und bestätige, dass nichts Sensibles zurückkommt.
• 42. Pro Nutzer UND global gelten Token-/Kosten-Obergrenzen auf jedem LLM-Calling-Endpoint. Test: Schicke von einem Konto aus massenhaft Requests und ein Kontingent greift. Beim Provider ist eine monatliche Ausgabenobergrenze mit Billing-Alerts gesetzt (Denial of Wallet, OWASP LLM10:2025).
• 43. LLM-Ausgabe, die als HTML gerendert wird, wird sanitisiert (DOMPurify), bevor sie das DOM erreicht. Modellausgabe ist untrusted Input, genau wie von Nutzern eingefügter Text.
• 44. Produktions-Agenten erzwingen Autorisierung serverseitig auf jedem Tool, unabhängig von der Entscheidung des Modells. Keine destruktive Aktion (Löschen, Zahlung, E-Mail-Versand) feuert allein auf das Wort des Modells hin.
• 45. Agent-Tools folgen dem Least-Privilege-Prinzip. Kein raw shell/exec/eval, das aus modellgesteuertem Input erreichbar ist. Destruktive Befehle stehen auf einer Allowlist und sind durch eine Bestätigung abgesichert (Excessive Agency, OWASP LLM06:2025).
• 46. Multi-Tenant-RAG/Vector-Stores erzwingen Tenant-Isolation zur Abfragezeit (Namespace- oder Metadaten-Filter, gebunden an den authentifizierten Nutzer), nicht im App-Code. Test: Tenant A kann niemals die Chunks von Tenant B abrufen (OWASP LLM08:2025).
• 47. RAG-Ingestion behandelt nutzergelieferte und gescrapte Dokumente als untrusted. Das Korpus ist versioniert mit Hash-Baselines, damit ein paar vergiftete Dokumente die Ausgabe nicht unbemerkt steuern können.
• 48. Vektor-Embeddings sind zugriffskontrolliert wie die darin kodierte PII (Embedding-Inversion kann Text rekonstruieren). Der Vektor-DB-Endpoint erfordert Auth und ist nicht öffentlich erreichbar.
• 49. Falls du MCP-Server auslieferst oder konsumierst: Jeder ist auf eine geprüfte Version gepinnt, Tool-Beschreibungen sind auf versteckte/unsichtbare-Unicode-Anweisungen gescannt (Tool Poisoning), und bei Änderungen verifizierst du erneut (Rug-Pull). MCP Inspector ≥ 0.14.1, mcp-remote ≥ 0.1.16 (CVE-2025-49596, CVE-2025-6514). Der Rug-Pull ist nicht theoretisch: postmark-mcp v1.0.16 hat eine Zeile hinzugefügt, die jede E-Mail darüber als BCC an den Angreifer schickte — ~300 Organisationen, ein Versionssprung (Sep. 2025).

Agent, Tooling & Supply Chain (12 Punkte)

• 50. Dev- und Prod-Datenbanken sind physisch getrennt mit getrennten Zugangsdaten. Dein Agent/CI hat niemals Prod-Schreib- oder DDL-Zugangsdaten. (Replits Agent hat während eines Code Freezes eine Produktions-DB gelöscht, weil er Schreibzugriff hatte, den er nie hätte haben dürfen.)
• 51. Cloud-Tokens für Agenten oder CI sind auf ein Projekt mit minimalen Berechtigungen beschränkt — niemals accountweit. (PocketOS: Ein unbeschränktes Railway-Token erlaubte einem Coding-Agenten, die Datenbank und jedes Backup in 9 Sekunden zu löschen.)
• 52. Der Supabase-service_role-Key taucht in null client-erreichbaren Dateien auf: grep -rn "service_role" src/ app/ public/ dist/ liefert nichts, und kein clientseitiges JWT hat einen role-Claim von service_role.
• 53. Jede Abhängigkeit wird vor der Installation darauf geprüft, dass sie tatsächlich existiert — echter Maintainer, echte Historie, echte Download-Zahlen. KI-vorgeschlagene Imports werden gegen die Lockfile abgeglichen. (Slopsquatting: 19,7 % der Pakete, die ein LLM empfiehlt, existieren nicht, 43 % dieser Namen treten vorhersehbar wieder auf, und Angreifer registrieren sie. Im Juli 2026 veröffentlichte ein untersuchter Claude-Agent funktionierende Malware auf dem echten PyPI — sie lief innerhalb einer Stunde auf 15 echten Systemen.) Hier kommt es auf deinen Scanner an: npm audit flaggt veröffentlichte CVEs, keine bösartigen Pakete. Siehe KNOWN-VULNERABLE-VERSIONS.md.
• 54. Backups / Point-in-Time-Recovery sind aktiviert, getestet UND unter Zugangsdaten gespeichert, die der Agent nicht erreichen kann — damit ein kompromittierter Agent nicht auch die BackupsWenn dir diese Checkliste erspart hat, etwas Peinliches auszuliefern, gib dem Repo einen Stern. Dann schick den Link an alle in deinem Team, die Lovable oder v0 benutzen, ohne bisher über dieses Zeug nachzudenken.