Vibe-Coding-Sicherheit

Bevor du deinen Launch twitterst, führe diese 69 Prüfungen aus. Sie entsprechen exakt den Mustern hinter der Lovable-RLS-CVE (CVE-2025-48757, 170+ Apps, 2025), dem Moltbook-Leak (1,5 Mio. API-Tokens, Feb. 2026) und dem Lovable-Plattform-Breach vom April 2026 (Quellcode + Service-Keys der Projekte anderer Nutzer, etwa 2,5 Monate lang exponiert).

Das komplette Kit gewünscht? 50 Audit-Skills, 15 .cursorrules, 1 MCP-Konfiguration + 4 CLI-Rezepte, 30 adversarial Review-Prompts, 10 Fallstudien. 5-Minuten-Installation. Pauschal 10 $.

→ rishabhvaai.gumroad.com/l/plddbd

---

In einem im Oktober 2025 veröffentlichten Audit hat Escape.tech 5.600 echte KI-generierte Apps über 14.600 Assets hinweg gescannt (Methodik). Sie meldeten 2.038 kritische Schwachstellen, 400+ geleakte Secrets und 175 Fälle von exponierter PII in 1.400 dieser Anwendungen (Ergebnisse). Die Secrets kamen direkt aus Frontend-Bundles: Stripe-, OpenAI- und Supabase-Keys im clientseitigen JavaScript. Seither hat sich nichts gebessert: Der GitGuardian-Report 2026 zählte 28,6 Mio. neue Secrets auf öffentlichem GitHub im Jahr 2025 (+34 % im Jahresvergleich), KI-Service-Secrets stiegen um 81 %, und Commits, die von Coding-Agenten mitverfasst wurden, leaken Secrets mit rund doppelt so hoher Rate wie die menschliche Baseline. Dies ist eine Checkliste mit 69 konkreten, testbaren Punkten. Jeder einzelne entspricht einem realen Incident-Muster. Wenn du alle 69 abhaken kannst, shippe. Wenn nicht, behebe, was dich blockiert.

Kein SaaS. Kein Scanner. Eine flache Liste, die du durchgehst, bevor du in die Produktion pushst.

---

Die 69-Punkte-Pre-Launch-Sicherheitscheckliste

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)