La maggior parte dei vibe coder pubblica ancora app con sicurezza zero. Si concentrano su funzionalità, design e velocità di rilascio. Le cose noiose sembrano compiti a casa.
Qualcuno sta pagando le conseguenze. Bollette Supabase da $200 in una notte. Inondazioni di spam il primo giorno. Qualcuno riceve lettere di diffida che non si aspettava.
E poi c'è un piccolo gruppo che esegue silenziosamente una checklist di 30 minuti prima di ogni lancio. Il genere di cose che non si vedono in una demo, ma che determinano se la tua app sopravviverà ai suoi primi veri utenti.
Ho condiviso una versione rapida di questo in un post. Ha fatto oltre 900.000 visualizzazioni, e le risposte e i DM chiedevano tutti la stessa cosa: l'analisi approfondita completa. Il contesto dell'agenzia. Le parti che ho dovuto tagliare per i limiti di caratteri. Quindi molti di voi l'hanno chiesto, ed eccolo qui, ora aggiornato per come stanno realmente le cose nel 2026.
Ho costruito oltre 60 MVP in agenzia in quasi 2 anni. Ho rilasciato prodotti in 21 giorni che sono andati direttamente in produzione. E ho imparato che la sicurezza non è qualcosa che aggiungi dopo. È qualcosa che integri prima del lancio, altrimenti paghi con incendi, rimborsi e danni alla reputazione.
Questo articolo è la versione completa. Inizia con ciò che uno sviluppatore con oltre 20 anni di esperienza ha condiviso su Reddit, poi lo integra con tutto ciò che eseguiamo su ogni progetto in agenzia prima di lasciare andare qualcosa in produzione.
Ecco l'analisi completa.
Cosa ha azzeccato il post di Reddit (e cosa ha perso)
Uno sviluppatore con oltre 20 anni di esperienza ha recentemente condiviso una checklist pre-lancio su Reddit che è diventata virale nella community del vibe coding. Era mirata. Cinque categorie. Prompt reali che puoi copiare in Claude o Cursor.
Ha centrato le basi.
→ Proteggiti legalmente prima di raccogliere anche una sola email
→ Usa l'AI per fare un audit della tua postura di sicurezza in 2 minuti
→ Allineati con OWASP, non solo con gli header di sicurezza
→ Controlla le perdite di dati nel frontend e nelle route API
→ Non inviare mai chiavi API al browser
Ma dopo aver fatto audit di dozzine di app create con vibe coding prima di quotare rebuild per i clienti, c'è un livello sottostante che quasi tutti i costruttori perdono.
Il post di Reddit copriva la superficie. Questo articolo copre le fondamenta sottostanti. Entrambi contano. Se ne fai solo uno, sei ancora esposto.
Il problema con l'approccio alla sicurezza della maggior parte dei vibe coder
La maggior parte dei costruttori tratta la sicurezza come una funzionalità che aggiungerà nella versione 2.
Non è una funzionalità. È il pavimento.
L'AI ti permette di rilasciare un prodotto in un weekend. Quella stessa velocità ti permette di rilasciare una responsabilità in un weekend. Il codice sembra pulito. L'interfaccia sembra curata. La demo funziona perfettamente. Niente di tutto questo ti protegge quando qualcuno apre DevTools e legge l'intero database.
Quando i fondatori vengono da noi in agenzia chiedendoci di ricostruire un MVP rotto, le stesse cinque categorie di fallimento si ripetono quasi sempre. Database aperti. Flussi di autenticazione che perdono informazioni. Chiavi API nei bundle del frontend. Nessun limite di velocità sugli endpoint costosi. Messaggi di errore che mappano l'intero schema per qualsiasi attaccante che li inneschi.
La soluzione non è la paranoia.
La soluzione è una checklist di 30 minuti che esegui prima di ogni lancio. Cinque categorie. La stessa che eseguiamo in agenzia. La stessa che sto per spiegarti.
Sezione 1: Proteggi te stesso, non solo la tua app
Nel momento in cui raccogli dati degli utenti, sei in territorio legale. GDPR. CCPA. Termini di servizio delle piattaforme.
La maggior parte dei vibe coder non ci pensa finché non è troppo tardi.
Tre minimi indispensabili.
→ Una vera informativa sulla privacy, anche se generata. Termly e PrivacyPolicies.com lo fanno entrambi gratuitamente in meno di 5 minuti.
→ Sapere esattamente dove vivono i tuoi dati utente. Regione Supabase, regione Vercel, eventuali servizi di terze parti che toccano i dati.
→ Niente di losco. Niente vendita di dati utente. Niente esportazione nella tua email personale. Niente password in chiaro.
Non perfetto. Solo non avventato.
Questi sono i 10 minuti di lavoro più economici che farai tutto l'anno, e sono la differenza tra un lancio normale e ricevere un'email di diffida alla seconda settimana.
Cosa è cambiato nel 2026, e perché questa sezione è ancora più importante ora.
Il terreno legale sotto le app costruite con l'AI è cambiato quest'anno, e la maggior parte dei costruttori non se n'è ancora accorta.
→ La Corte Suprema ha lasciato valida la sentenza sulla paternità umana. Il codice scritto puramente dall'AI non può essere coperto da copyright negli USA. Se un concorrente clona la tua app costruita con l'AI riga per riga, potresti non avere alcun margine legale per fermarlo.
→ Se la tua AI incorpora silenziosamente codice open-source sotto una licenza come GPL, puoi essere costretto a rendere open-source l'intero codice, o affrontare una causa per violazione. Ottieni tutta la responsabilità e nessuna protezione.
→ Il più grande caso di copyright sull'AI finora si è concluso con un accordo da 1,5 miliardi di dollari, e ha ricevuto l'approvazione finale del tribunale questa settimana. Gli avvocati non stanno arrivando. Sono già qui.
Niente di tutto questo significa smettere di costruire. Significa smettere di rilasciare alla cieca. Il resto di questa checklist è come farlo.
Sezione 2: Blocca il tuo database
Questa è la sezione su cui passiamo più tempo quando facciamo audit dei progetti in arrivo. Quasi ogni app creata con vibe coding che abbiamo mai aperto fallisce almeno uno dei tre controlli qui sotto.
Row Level Security su Supabase.
Senza RLS, chiunque può aprire DevTools del browser, eseguire una query e leggere l'intero database. Non hacking. Non exploit. Solo aprire la console e digitare un comando.
Vai al tuo pannello di controllo Supabase. Clicca Authentication, poi Policies. Se vedi zero policy, la tua app è nuda.
La soluzione è semplice. Aggiungi policy che limitano chi può leggere, inserire, aggiornare o eliminare righe in base all'utente autenticato. Se usi Lovable o Bolt, chiedi semplicemente all'agente di abilitare RLS e scrivere policy per le tue tabelle. Genererà automaticamente il SQL.
5 minuti. La differenza tra un'app sicura e una violazione dei dati in attesa di accadere.
Validazione lato server su ogni modulo.
Zod sul client non è sicurezza. È UX.
Gli attaccanti disabilitano JavaScript, aprono Postman e inviano quello che vogliono direttamente alla tua API. Se la tua unica validazione è sul frontend, possono inviare dati malformati, tentativi di SQL injection o script. Se il tuo modulo scrive nel database, validalo ANCORA sul server. Controlla i tipi di dati. Controlla i limiti di lunghezza. Pulisci gli input.
Questo è il minimo indispensabile. Non opzionale.
Messaggi di errore che non perdono dati.
Messaggio di errore sbagliato. "SELECT * FROM users WHERE email fallito."
Questo dice a un attaccante i nomi delle tue tabelle, i nomi delle colonne e la logica delle query.
Messaggio di errore corretto. "Utente non trovato."
Registra gli errori completi lato server con contesto. Mostra messaggi generici agli utenti. Non esporre mai stack trace in produzione. Sicurezza operativa di base. La maggior parte delle app fallisce questo il primo giorno.
I messaggi sbagliati consegnano il tuo schema agli attaccanti. I messaggi corretti non rivelano nulla.
Un prompt. La maggior parte delle tue vulnerabilità OWASP segnalate in 30 secondi.
Sezione 3: Testa i casi di fallimento sull'autenticazione
La maggior parte degli sviluppatori testa solo il percorso felice. Registrati con un'email valida. Accedi. Il gioco è fatto.
Le app si rompono quando le cose vanno male. Ed è esattamente lì che gli attaccanti sondano per primi.
Ecco il test esatto in 4 punti sui casi di fallimento che eseguiamo prima di approvare qualsiasi progetto.
→ Accedi con la password sbagliata 5 volte di fila. Blocca l'account? Mostra un errore generico o conferma che l'email esiste?
→ Reimposta la password per un'email che non esiste. Rivela se l'email è nel sistema?
→ Clicca il link di verifica email due volte. Rompe il flusso o lo gestisce correttamente?
→ Registrati con un'email già registrata. Rivela che l'utente esiste già?
10 minuti di test. Cattura l'80% delle vulnerabilità di autenticazione prima che vadano in produzione.
Abbiamo eseguito questo stesso test su ogni audit in arrivo che abbiamo fatto quest'anno. Ha individuato problemi in circa 7 codebase su 10. I vibe coder con interfacce bellissime li hanno persi ogni volta.
Sezione 4: I 4 prompt AI che esegui prima di ogni lancio
Questa è la parte che il post di Reddit ha centrato. Questi quattro prompt coprono l'80% dell'audit di sicurezza di superficie e richiedono circa 8 minuti in totale.
Li esegui dentro Claude Code, Cursor, o qualsiasi agente con cui costruisci. Salvali. Rendili parte del tuo rituale di lancio.
Prompt 1. Postura di sicurezza di base.
Rivedi la mia app come specialista di sicurezza e assicurati che abbia
strong security headers and a solid baseline security posture.
2 minuti. Risolve le lacune più evidenti. Gli header da soli non bastano, ma sono il pavimento.
Prompt 2. Verifica standard OWASP.
Rivedi la mia app secondo gli standard OWASP e evidenzia le vulnerabilità.
È qui che SQL injection, XSS e problemi di autenticazione vengono effettivamente individuati.
Prompt 3. Audit di perdita dati.
Controlla la mia app per eventuali perdite di credenziali o dati sensibili nel
frontend o nelle route API.
Il codice generato dall'AI perde dati in 3 posti quasi ogni volta. Valori .env che finiscono nel codice frontend. Risposte API che restituiscono troppi dati. Segreti che compaiono nei log.
Prompt 4. Verifica esposizione chiavi API.
Assicurati che nessuna chiave API sia esposta nel codice frontend o nelle chiamate di rete.
Se la tua chiave è nel browser, presumi che sia già stata presa. Questo singolo bug ha prosciugato interi progetti indie in un solo weekend.
Approfondimento sulle chiavi API.
Quel prompt cattura i casi evidenti. Ecco la regola che applichiamo su ogni progetto oltre a quello.
Le chiavi pubbliche possono stare nel frontend. Chiavi anonime di Supabase, chiavi pubblicabili di Stripe, qualsiasi cosa esplicitamente marcata come pubblica. Sono progettate per essere esposte.
Le chiavi segrete devono stare lato server. Chiavi di ruolo di servizio, chiavi segrete di Stripe, chiavi OpenAI, qualsiasi cosa senza un prefisso "pubblicabile". Conservale in Supabase Edge Function Secrets o nelle variabili d'ambiente di Vercel. Non commetterle mai nel controllo versione. Non incollarle mai nel tuo codice frontend.
Se pensi che una chiave possa essere stata esposta, rigenerala immediatamente. Non aspettare. Non sperare che nessuno l'abbia trovata. I repository GitHub pubblici vengono scansionati per le chiavi in pochi minuti.
Due minuti per sapere se i tuoi header di sicurezza stanno facendo qualcosa.
Sezione 5: Proteggi la tua infrastruttura
Questa è la sezione che protegge il tuo portafoglio, non solo i tuoi dati.
Limiti di velocità su ogni endpoint.
Questo è il modo più veloce con cui un'app creata con vibe coding svuota il tuo portafoglio. Senza limiti di velocità, qualcuno può spammanare la tua API 10.000 volte in un minuto. Magari per forzare un login. Magari per raschiare il tuo database. Magari solo per essere malevolo.
Ho personalmente visto una bolletta Supabase saltare da $20 a $200 in un solo giorno su un progetto secondario perché un endpoint non aveva limiti di velocità. Succede velocemente.
Tre minimi indispensabili.
→ Limita la velocità di ogni endpoint che colpisce un'API a pagamento (OpenAI, Anthropic, Stripe, Resend)
→ Imposta limiti giornalieri rigidi nei pannelli di controllo di OpenAI e Anthropic
→ Imposta avvisi al 50% del tuo limite giornaliero in modo da cogliere un picco prima che ti colpisca al mattino
Per Supabase Edge Functions, Upstash è la soluzione più semplice per i limiti di velocità. 100 richieste al minuto per IP sugli endpoint pubblici, 1.000 al minuto per utenti autenticati è una base di partenza sensata.
CAPTCHA su ogni modulo pubblico.
Moduli di contatto, pagine di registrazione, liste d'attesa. Senza CAPTCHA, i bot ti inondano il primo giorno. Abbiamo visto moduli di contatto raccogliere 500 invii di spam in un'ora su app senza protezione.
Cloudflare Turnstile è gratuito e incentrato sulla privacy. L'integrazione richiede 10 minuti.
Restrizioni CORS sulla tua API.
Di default, molti framework permettono richieste API da qualsiasi parte. Va bene per lo sviluppo locale. Un disastro in produzione.
Specifica esattamente quali domini possono accedere alla tua API. Permetti il tuo dominio di produzione. Permetti localhost per i test. Blocca tutto il resto. 2 minuti. Previene il cross-site request forgery e l'accesso API non autorizzato.
Limiti rigidi e avvisi. L'impostazione da 3 minuti che salva la tua bolletta mensile.
Esegui la scansione di sicurezza integrata per ultima
I 4 prompt della Sezione 4 sono manuali. Li incolli e leggi cosa torna. Da 3 giorni fa, hai qualcosa di meglio per il cancello finale.
Anthropic ha appena rilasciato un plugin Claude Security per Claude Code.
È in beta, rilasciato il 22 luglio, e non è un singolo prompt. È uno scanner di vulnerabilità multi-agente che gira direttamente nel tuo terminale. Installalo all'interno di una sessione di Claude Code:
/plugin install claude-security@claude-plugins-official poi /reload-plugins. Questo ti dà un comando, /claude-security.
Cosa lo rende diverso dall'incollare un prompt.
→ Un team di agenti mappa la tua architettura, costruisce un modello di minaccia, poi caccia in 4 categorie: injection, autenticazione e accesso, memoria, e crittografia e segreti
→ Ogni risultato deve sopravvivere a un panel avversario di 3 agenti prima di arrivare al tuo rapporto, quindi non devi destreggiarti tra falsi positivi
→ Il rapporto ti dà gravità, ID CWE, e il file e la riga esatti, e può trasformare i risultati in file di patch che puoi rivedere e applicare tu stesso
→ Il modello alla base ha già trovato oltre 500 vulnerabilità ad alta gravità precedentemente sconosciute in codebase open-source
Hai bisogno di un piano Claude Code a pagamento (v2.1.154 o più recente), e le scansioni usano i token del tuo piano.
Anche Cursor e i costruttori visivi come Lovable rilasciano i propri scanner che segnalano configurazioni RLS errate, segreti esposti, dipendenze vulnerabili e pattern insicuri. Esegui quello che il tuo stack ha.
Risolvi tutto ciò che segnalano. Non rilasciare con avvisi. Non dire a te stesso che lo risolverai dopo. Il debito di sicurezza si accumula più velocemente del debito di funzionalità.
Tratta questa scansione come il cancello finale prima del deploy. I prompt manuali catturano ciò che lo scanner perde. Lo scanner cattura ciò che dimentichi di chiedere. Ora che Anthropic ha costruito uno scanner vero in Claude Code, non c'è scusa per saltarlo.
Quando usare questa checklist
Questa checklist è pensata per l'80% dei costruttori che rilasciano MVP, SaaS, strumenti AI, o qualsiasi cosa con dati utente.
Usala quando.
→ Stai rilasciando un'app che raccoglie dati utente, anche solo un'email
→ Stai eseguendo su Supabase, Firebase, o qualsiasi backend con accesso al database
→ Stai chiamando API a pagamento (OpenAI, Anthropic, Stripe) dal tuo codice
→ Stai per condividere la tua app pubblicamente per la prima volta
Introducila gradualmente quando.
→ Stai rilasciando strumenti interni usati solo dal tuo team dietro autenticazione
→ Stai lavorando con un team di sicurezza che esegue già un audit più completo
→ Sei in modalità esplorazione pre-MVP e non stai raccogliendo dati utente
Per la maggior parte dei vibe coder che rilasciano qualcosa di reale, ogni elemento di questa lista si applica. Saltarne uno qualsiasi significa assumersi una responsabilità che non ti serve.
Cosa tenere d'occhio
Alcuni avvertimenti onesti prima di considerare questa come parola finale.
Questa checklist ti porta a una base di partenza solida, non a una conformità da livello enterprise. Se stai archiviando dati sanitari, dati finanziari, o qualsiasi cosa regolamentata, hai bisogno di un vero audit di sicurezza in aggiunta.
I prompt AI e gli scanner catturano problemi di superficie. Non catturano vulnerabilità di logica di business, bug complessi di stato di autenticazione, o attacchi di injection sofisticati. Trattali come il pavimento, non il soffitto.
Il debito di sicurezza si accumula. Più aspetti, più dolorosa sarà la pulizia. Esegui questa checklist prima di ogni lancio, non solo all'inizio.
Le policy RLS sono facili da scrivere in modo errato. Testarle cercando di accedere ai dati come un utente diverso. Abilitare RLS senza testare è peggio che non averlo perché crea falsa fiducia.
Cosa significa realmente
Ecco la mia opinione sincera.
L'economia del vibe coding sta maturando rapidamente. Un anno fa potevi rilasciare qualsiasi cosa e a nessuno importava. Ora le piattaforme impongono policy di sicurezza. Gli utenti se lo aspettano. Gli investitori lo controllano. I tribunali hanno tracciato linee reali quest'anno, e gli avvocati hanno iniziato a farsi vedere.
I 30 minuti che salti prima del lancio ti costeranno 30 giorni di incendi quando qualcosa si rompe. Lo abbiamo visto succedere in multipli audit in arrivo quest'anno, dove i fondatori sono venuti da noi chiedendo un rebuild dopo che la loro prima versione aveva iniziato a perdere dati o bruciare soldi.
In agenzia trattiamo questa checklist come il deploy. Non è opzionale. Fa parte del rilascio. E ora che Anthropic ha integrato uno scanner di sicurezza direttamente in Claude Code, il divario tra i costruttori che eseguono questa checklist e i vibe coder che la saltano si allargherà ancora più velocemente.
Non devi essere paranoico. Non hai bisogno di sicurezza da livello enterprise il primo giorno. Hai solo bisogno di questa checklist.
Eseguita prima di ogni lancio. Rendila parte del tuo flusso di lavoro. Trattala come il test o il deploy.
Perché le app che sopravvivono nel 2026 non sono solo quelle che rilasciano velocemente. Sono quelle che rilasciano velocemente e non si rompono quando arrivano i veri utenti.
Il 2026 sarà IMPLACABILE per i costruttori che trattano la sicurezza come un flusso di lavoro invece che un ripensamento.
TL;DR
→ I vibe coder vengono citati in giudizio, multati e prosciugati. La maggior parte non se n'è ancora accorta.
→ Novità nel 2026: il codice solo AI non può essere coperto da copyright negli USA, la contaminazione GPL può costringerti a rendere open-source l'intera app, e il più grande accordo sul copyright AI della storia (1,5 miliardi di $) ha appena ricevuto l'approvazione finale del tribunale. Proteggiti prima.
→ Passo 1. Proteggiti legalmente. Informativa sulla privacy, posizione dei dati, nessuna gestione losca.
→ Passo 2. Blocca il tuo database. RLS su Supabase, validazione lato server su ogni modulo, messaggi di errore che non perdono dati.
→ Passo 3. Testa i casi di fallimento sull'autenticazione. Password sbagliata 5 volte. Reimposta password per email finta. Link di verifica cliccato due volte. Registrazione con email esistente.
→ Passo 4. Esegui i 4 prompt AI di sicurezza. Postura di sicurezza. OWASP. Perdite dati. Esposizione chiavi API.
→ Blocca le variabili d'ambiente. Le chiavi pubbliche possono vivere nel frontend. Le chiavi segrete vanno in Supabase Edge Function Secrets o nelle variabili d'ambiente di Vercel. Se esposte, rigenerale immediatamente.
→ Passo 5. Proteggi la tua infrastruttura. Limita la velocità di ogni endpoint. Imposta limiti rigidi sulle API a pagamento. CAPTCHA sui moduli pubblici. Restrizioni CORS sulla tua API.
→ Esegui uno scanner reale come cancello finale. Il nuovo plugin Claude Security di Anthropic esegue una scansione multi-agente direttamente nel tuo terminale. Beta, piani Claude Code a pagamento.
→ Questo richiede 30 minuti. Eseguito prima di ogni lancio.
→ Il divario tra i costruttori che eseguono questa checklist e quelli che la saltano si allargherà rapidamente nel 2026.
Post completo di Reddit che ha scatenato tutto. https://www.reddit.com/r/vibecoding/comments/1sthzcj/if_youre_about_to_launch_a_vibe_coded_app_read/
Fai uno screenshot. Eseguita prima di ogni lancio.
Andiamo.
