Sicurezza del Vibe Coding

Prima di twittare il tuo lancio, esegui questi 69 controlli. Corrispondono esattamente ai pattern alla base della CVE RLS di Lovable (CVE-2025-48757, 170+ app, 2025), della fuga di Moltbook (1,5 milioni di token API, feb 2026) e della violazione della piattaforma Lovable dell'aprile 2026 (codice sorgente e chiavi di servizio dei progetti di altri utenti, esposti per ~2,5 mesi).

Vuoi il kit completo? 50 skill di audit, 15 .cursorrules, 1 config MCP + 4 ricette CLI, 30 prompt di review adversarial, 10 case study. Installazione in 5 minuti. $10 fissi.

→ rishabhvaai.gumroad.com/l/plddbd

---

In un audit pubblicato a ottobre 2025, Escape.tech ha analizzato 5.600 app reali generate da AI su 14.600 asset (metodologia). Ha segnalato 2.038 vulnerabilità critiche, oltre 400 segreti trapelati e 175 casi di PII esposte in 1.400 di quelle applicazioni (risultati). I segreti provenivano direttamente dai bundle frontend: chiavi Stripe, OpenAI e Supabase nel JavaScript lato client. Da allora non è migliorato: il report 2026 di GitGuardian ha contato 28,6 milioni di nuovi segreti su GitHub pubblico nel 2025 (+34% su base annua), segreti di servizi AI in aumento dell'81% e commit co-autorati da agenti di coding che fanno trapelare segreti a un ritmo circa 2 volte superiore alla media umana. Questa è una checklist di 69 elementi specifici e verificabili. Ognuno corrisponde a un pattern di incidente reale. Se riesci a spuntarli tutti e 69, pubblica. Se non ci riesci, correggi ciò che ti blocca.

Non è un SaaS. Non è uno scanner. Un semplice elenco da scorrere prima di fare push in produzione.

---

La Checklist di Sicurezza Pre-Lancio in 69 Punti

Sei a 30 minuti dal lancio. Fermati. Esegui prima questo.

La sola vulnerabilità RLS di Lovable (CVE-2025-48757, 2025, CVSS 9.3) ha esposto oltre 170 app in produzione. Moltbook ha esposto 1,5 milioni di token API a febbraio 2026 — interrogabili con una singola curl. Non erano casi limite. Erano lanci mainstream.

Questa checklist raggruppa 69 elementi specifici e verificabili tra autenticazione, segreti, API, database, frontend, AI/LLM, strumenti per agenti e deployment. Se non riesci a spuntarli tutti e 69, non pubblicare.

---

Autenticazione (8 elementi)

• 1. La Row-Level Security (RLS) del database è abilitata su ogni tabella del database.
• 2. Esistono policy RLS per ogni tabella e ogni ruolo (anon, authenticated, service_role).
• 3. I token JWT sono validati lato server su ogni rotta API protetta (non fidarti mai del frontend per validare l'autenticazione).
• 4. Le sessioni vengono ruotate o invalidate dopo il login (protezione CSRF + session fixation).
• 5. I magic link (auth passwordless) sono monouso, scadono in meno di 15 minuti e sono legati all'IP dell'utente o all'impronta del dispositivo.
• 6. Non puoi aggiornare o eliminare utenti, ordini o record sensibili basandoti solo su ID forniti dall'utente. Test: prova ad aggiornare il record di un altro utente cambiando l'ID nella richiesta.
• 7. I token CSRF sono validati sulle richieste che modificano lo stato (POST, PUT, DELETE) tramite double-submit cookie o SameSite=Strict.
• 8. I cookie di sessione hanno i flag HttpOnly, Secure e SameSite=Strict impostati.

Segreti e Ambiente (7 elementi)

• 9. Nessun segreto nelle variabili NEXT_PUBLIC_*, nei file .env di Vue/React o in stringhe hardcoded. Fai un grep di NEXT_PUBLIC_ e controlla tutte le variabili.
• 10. .env, .env.local, .env.*.local sono in .gitignore e non vengono mai committati. Controlla la cronologia git: git log --all -p | grep -i "api_key\|secret".
• 11. La chiave service_role di Supabase è SOLO nel .env lato server (Node, Python, Go, ecc.), mai nei bundle frontend o in .env.local. La chiave service_role bypassa completamente la RLS — una singola fuga equivale a lettura/scrittura completa su ogni tabella.
• 12. Chiavi Stripe: chiave pubblica in NEXT_PUBLIC_*, chiave segreta solo lato server, firma del webhook verificata.
• 13. Le chiavi API di OpenAI, Anthropic e xAI non sono mai nel codice frontend; passano sempre tramite proxy tramite la tua API.
• 14. Nessuna chiave API, URL di database o credenziale hardcoded nel sorgente (inclusi commenti e codice inutilizzato).
• 15. I segreti vengono ruotati dopo il lancio o se sono mai stati esposti nella cronologia del sorgente.

Hardening delle API (10 elementi)

• 16. Il rate limiting è attivo su /api/auth/*, /api/login, /api/register. Test: 100 richieste/minuto dovrebbero restituire 429.
• 17. Tutti gli input utente verso /api/* sono validati con Zod, Yup o simili prima di toccare il database. Nessun req.body grezzo passato alle query.
• 18. Nessun mass assignment: l'utente non può impostare admin=true, role=admin o altri campi sensibili inviandoli via POST.
• 19. Le firme dei webhook sono verificate (confronta l'header della firma HMAC-SHA256 con il valore atteso usando un confronto a tempo costante).
• 20. CORS non è impostato su *. Le origini consentite sono hardcoded e non includono localhost in produzione.
• 21. Le query SQL usano solo statement parametrizzati. Nessuna concatenazione di stringhe di input utente in SQL.
• 22. Le query NoSQL (MongoDB, Firebase, ecc.) non concatenano input utente in filtri o selettori.
• 23. Gli upload di file sono validati (tipo mime + dimensione), memorizzati fuori dalla web root e rinominati per prevenire path traversal.
• 24. I redirect post-login sono in whitelist. Non è possibile reindirizzare a un dominio esterno tramite open redirect.
• 25. L'API non effettua richieste esterne non validate. Assicurati che gli URL usati nelle richieste lato server provengano dalla tua allowlist, non da input utente (prevenzione SSRF).

Database (6 elementi)

• 26. La RLS è APPLICATA su tutte le tabelle. Il ruolo anon non può fare SELECT/INSERT/UPDATE/DELETE su nessuna tabella senza una policy esplicita che lo conceda.
• 27. Il ruolo pubblico anon ha zero permessi di default. Le policy concedono solo ciò che serve. Sola lettura sulle liste pubbliche, mai scrittura.
• 28. La chiave service-role è usata SOLO nel codice lato server. Verifica: grep -r "service_role" src/. Nei file frontend dovrebbe restituire zero risultati.
• 29. Isolamento dei dati utente: le query filtrano sempre per auth.uid() o team_id. Nessuna query restituisce tutti i record di tutti gli utenti.
• 30. Le soft delete (flag is_deleted) o le tabelle di archivio prevengono la perdita accidentale di dati. Le hard delete sono registrate con attore + timestamp.
• 31. I backup del database esistono e sono testati. Hai verificato di poter ripristinare da un backup prima di questo lancio.

Frontend (8 elementi)