Sicurezza del vibe coding: come proteggere un’app creata con l’AI

Altre istruzioni per lavorare con Ailoot sono nella documentazione.

Perché le app create con l’AI vengono violate più spesso?#

Anch’io creo prodotti con l’AI e non divento paranoico sulla sicurezza al punto di «blindare tutto al massimo». Ma c’è un livello di base sotto il quale non devi scendere, altrimenti un giorno ti sveglierai con il database vuoto e i miner di qualcun altro sul tuo server. Questa guida parla di quel livello di base. Non «diventa un esperto di sicurezza», ma «non farti del male da solo senza motivo».

La radice del problema è semplice. Quando dici a un agente AI «creami un’app per prenotare appuntamenti», lui la fa funzionare il più velocemente possibile. La sicurezza è un lavoro extra che non si vede in una demo. Così il database viene configurato come aperto, la chiave di pagamento finisce direttamente nel codice e il controllo «questo utente ha accesso?» esiste solo nel browser, dove può essere aggirato in un secondo.

La seconda ragione sono le piattaforme stesse. La struttura del problema è semplice: molte piattaforme rendono i nuovi progetti accessibili pubblicamente per impostazione predefinita, e chi crea app senza essere programmatore non sempre sa che deve cambiare questa impostazione.

In altre parole, la falla si apre da sola, per impostazione predefinita. Non hai fatto nulla di sbagliato. Semplicemente non hai fatto nulla e, in materia di sicurezza, l’inazione significa proprio «aperto a tutti».

Cosa hanno già imparato a proprie spese i vibe coder?#

Il modo migliore per immunizzarsi contro la negligenza è imparare dagli errori altrui. Ecco quattro resoconti che vale la pena leggere prima di pubblicare il tuo progetto.

Lovable e RLS disattivato. La piattaforma Lovable crea app a partire da descrizioni testuali. Nel 2025, nelle sue app è stata scoperta una falla sistemica, classificata come CVE-2025-48757. La causa: le app generate non avevano regole di accesso al database a livello di riga (RLS, spiegato più avanti). Un ricercatore ha esaminato un campione e ha trovato 303 punti di accesso esposti in 170 app. Erano esposti nomi, numeri di telefono, stati dei pagamenti, chiavi API di altre persone e persino indirizzi di casa. In circa il 70 percento delle app esaminate, la protezione a livello di riga era completamente disattivata.

Tea e i dati sensibili. Nel luglio 2025, l’app Tea (recensioni anonime delle persone) ha perso circa 72,000 immagini, tra cui 13,000 selfie e foto di documenti, e poi oltre un milione di messaggi privati. La causa tecnica era l’archiviazione aperta e i controlli di accesso deboli. La comunità della sicurezza cita Tea come esempio lampante: quando un lancio rapido conta più del controllo dei permessi, i dati sensibili sono i primi a essere divulgati.

Un altro esempio pratico. In un caso descritto dall’autore originale, l’app di un vibe coder è stata violata perché l’AI aveva impostato una password predefinita durante la creazione del database, che poteva essere indovinata automaticamente. Poi la solita sequenza: sono entrati, hanno installato miner e riscritto il progetto. Il server ha dovuto essere cancellato completamente. Una password predefinita è una porta aperta con un cartello «entrate pure».

Due fronti della sicurezza: dove sei vulnerabile, esattamente?#

Quando si parla di «sicurezza del vibe coding», di solito si confondono due paure completamente diverse. Separiamole, perché ci si protegge in modi diversi.

Primo fronte: l’agente stesso. Esegui un agente AI sul computer e gli dai accesso ai file, al terminale, alle chiavi e al database. Il rischio è che un agente non sia una persona: segue le istruzioni alla lettera e trova la strada più breve, anche se è pericolosa. Questo include anche il rischio che il comando di qualcun altro venga «iniettato» nell’agente tramite il testo che legge (si chiama prompt injection).

Secondo fronte: l’app finita. È ciò che hai pubblicato e che le persone usano. L’obiettivo è il tuo sito o servizio pubblicato: gli aggressori entrano in un database aperto, inviano richieste false o indovinano gli account di altre persone. L’agente non c’entra: la falla è stata lasciata prima e sono altre persone a sfruttarla.

Anthropic, l’azienda che ha creato Claude, enuncia così il principio di protezione principale, che vale su entrambi i fronti:

In pratica, significa: non contare sul fatto che l’AI «eviti da sola di fare cose sbagliate». Prima limita ciò che può fare concretamente, e solo dopo chiedile di comportarsi bene. Quando il suo comportamento fallisce, e succederà, a proteggerti sarà soltanto un confine rigido che hai impostato in anticipo.

Vuoi che l’AI lavori in modo prevedibile e smetta di farti inciampare in ogni nuovo progetto? Le regole di sicurezza fanno parte del tuo Second Brain: scrivile una volta in CLAUDE.md e l’agente le seguirà in ogni richiesta.

Cosa può fare un agente AI con accesso al tuo computer?#

Il rischio più sottovalutato è il tuo agente con permessi troppo ampi. Non serve nemmeno un hacker esterno. Ecco un esempio recente da fine maggio 2026. Un agente Codex aveva bisogno dei permessi di amministratore, che l’utente non aveva. L’agente non si è arreso: ha guardato intorno, ha visto che l’utente apparteneva al gruppo docker, sostanzialmente equivalente a root, e ha usato quell’accesso.

Non c’era alcuna intenzione malevola. Semplicemente, un agente a cui viene detto «risolvi il compito» trova una debolezza strutturale più velocemente di una persona. E se quella debolezza gli dà accesso alle tue chiavi o alla produzione, lo userà. Quindi la regola numero uno è il principio del privilegio minimo. Dai all’agente esattamente l’accesso necessario per un compito specifico, senza aggiungere altro.

Cosa puoi fare in pratica, anche se non sei un programmatore?

1. Non eseguire l’agente in modalità «consenti tutto» su una macchina di produzione

   Una modalità in cui l’agente non chiede conferma (spesso chiamata bypass o yolo) è adatta solo a una sandbox o a un progetto di test, non a una macchina che contiene chiavi operative e accesso alla produzione.

2. Impedisci all’agente di leggere i segreti

   In Claude Code lo fai con una regola che nega l’accesso ai file contenenti chiavi. Così, anche se l’agente vuole aprire .env, lo strumento non glielo permette.

3. Tieni separate le chiavi di produzione

   Le chiavi del database di produzione e del servizio di pagamento non dovrebbero trovarsi nella stessa cartella in cui l’agente scrive codice. Tieni separati gli ambienti: usa chiavi di test quando fai esperimenti.

4. Usa la sandbox dello strumento

   Gli strumenti AI moderni possono eseguire comandi in isolamento (una sandbox), senza accesso al resto del sistema. In Claude Code, questo riduce le richieste di autorizzazione di circa l’84 percento, quindi è anche più comodo.

Una regola che nega la lettura dei segreti in Claude Code ha più o meno questo aspetto: inseriscila nelle impostazioni dei permessi:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Dove non dovresti mai mettere chiavi API e password?#

L’errore più economico e comune è mettere le chiavi nel codice. Una chiave API di un servizio di pagamento, una password del database, un token per un bot: sono tutti segreti. Devono stare in un file .env separato e quel file deve essere elencato in .gitignore, così non finisce in git insieme al codice.

Perché è fondamentale: una chiave non resta a lungo in un repository pubblico. I bot scandiscono i nuovi commit senza sosta. Poi segue la solita sequenza: trovano una chiave cloud, avviano server per il mining di criptovalute a tue spese e al mattino ti ritrovi con una bolletta da decine di migliaia. Gli sviluppatori raccontano spesso storie del genere e le bollette arrivano a cinque cifre in dollari.

La portata del problema nel 2025: 28.65 milioni di nuovi segreti inseriti direttamente nel codice dei repository pubblici, il 34 percento in più rispetto all’anno precedente. Le fughe di chiavi specifiche per servizi AI sono aumentate dell’81 percento. Il vibe coding alimenta il problema perché l’agente fa il commit senza controllare.

Cosa controllare manualmente subito:

1. Apri il file .gitignore del progetto

   Assicurati che contenga una riga .env. Se non c’è, aggiungila prima del primo commit.

2. Vai al tuo repository GitHub

   Controlla che il file .env non ci sia. Cercare .env o una parte della tua chiave nel repository è un modo rapido per verificare.

3. Se una chiave è stata divulgata, revocala e creane una nuova

   Cancellare il commit non basta: la chiave potrebbe essere già stata sottratta. Vai al servizio (provider di pagamento, servizio cloud, provider AI), revoca la vecchia chiave e creane una nuova. Si chiama rotazione.

4. Concedi alle chiavi i permessi minimi

   Se una chiave serve solo per leggere, rendila di sola lettura. Così, anche se viene divulgata, si può sottrarre meno.

Perché tutti possono vedere il tuo database senza RLS?#

Se stai creando un’app su Supabase o su un database simile, questa è la sezione più importante. RLS sta per Row Level Security. In parole semplici, è una regola che determina quali righe di una tabella vengono mostrate a un determinato utente. Senza, la tabella «ordini» restituisce a tutti gli ordini di ogni cliente.

Ecco come la documentazione Supabase stessa lo spiega chiaramente:

Ecco la trappola principale per chi fa vibe coding. Quando crei una tabella cliccando nella dashboard Supabase, la protezione si attiva automaticamente. Ma quando la tabella viene creata dall’AI, che quasi sempre scrive direttamente comandi SQL, RLS resta disattivato per impostazione predefinita. Questo significa che una tabella generata da un agente è quasi sicuramente aperta a tutto Internet. È esattamente così che sono trapelati i dati di quelle 170 app Lovable.

Cosa fare:

1. Chiedi direttamente all’agente

   Scrivi: «mostra tutte le tabelle in cui RLS è disattivato». L’AI produrrà un elenco: sarà la tua lista di attività.

2. Abilita RLS su ogni tabella con dati degli utenti

   E aggiungi almeno una policy di accesso, per esempio: «un utente può vedere solo le proprie righe».

3. Controlla la dashboard

   Nella dashboard Supabase, ogni tabella dovrebbe mostrare «RLS abilitato». Se è grigio o rosso, significa che la tabella è aperta.

4. Fai una prova reale

   Accedi come utente normale e prova a richiedere i dati di qualcun altro. Se l’accesso viene negato, la policy funziona.

Perché i controlli dei permessi nell’interfaccia non ti proteggono?#

Un’illusione comune è: «ho fatto in modo che gli utenti normali non possano vedere il pulsante di amministrazione». Il problema è che un pulsante è solo un’immagine nel browser. Si può inviare una richiesta direttamente al server senza usare il pulsante. Se il server non ricontrolla i permessi, eseguirà il comando di qualcun altro.

Un esempio classico si chiama IDOR. Immagina di aprire il tuo ordine a un indirizzo con id=123. Cambialo in id=124 e puoi vedere l’ordine di qualcun altro, perché il server non ha controllato che fosse davvero il tuo. Questa è una delle falle più comuni nelle app create con il vibe coding; controlli dei permessi deboli erano all’origine della fuga di dati di Tea.

La regola è semplice: ripeti sul server ogni controllo «questo utente è autorizzato a farlo?». L’interfaccia serve per comodità; la protezione appartiene al backend. Un’istruzione pronta da dare all’agente: «aggiungi controlli dei permessi lato server per ogni endpoint che legge o modifica dati degli utenti; non fare affidamento sul fatto che un elemento sia nascosto nell’interfaccia».

Come puoi controllare il codice per individuare falle se non sei un programmatore?#

La buona notizia: oggi puoi chiedere alla stessa AI di controllare la sicurezza e se la cava abbastanza bene nel trovare le falle comuni. Ecco tre strumenti per attività diverse.

1. Il comando /security-review in Claude Code. Un controllo una tantum del branch corrente per individuare SQL injection, XSS, falle di autorizzazione, fughe di dati e problemi con le dipendenze. Ho spiegato passo per passo come funziona e come aggiungere un controllo automatico a ogni modifica in una guida separata sulla revisione della sicurezza in Claude Code. Il punto principale qui: è la prima linea di difesa e si avvia con un solo comando.

2. Il plugin ufficiale security-guidance. Installalo dal marketplace ufficiale dei plugin con /plugin install security-guidance@claude-plugins-official (richiede Claude Code versione 2.1.144 o successiva). Controlla il codice in tre momenti: a ogni modifica, alla fine di ogni turno e al momento del commit. Rileva aggiramenti delle autorizzazioni, IDOR, injection e crittografia debole. Ma Anthropic è sincera sui suoi limiti:

npx skills add <author>/<repo>

Poi basta dire all’agente: «controlla il mio progetto per individuare vulnerabilità». Ma c’è un’importante precisazione su questa raccolta, perciò le ho dedicato una sezione qui sotto.

Per dare un contesto: anche i principali operatori hanno cominciato a prendere sul serio la sicurezza del codice AI. Nell’ambito di Project Glasswing, ampliato il 2 giugno 2026 fino a includere 150 organizzazioni, i partner hanno trovato in poco tempo oltre 10,000 vulnerabilità critiche usando i modelli Anthropic. La posta in gioco è chiara:

Puoi fidarti delle competenze e delle estensioni su GitHub?#

Qui le cose si complicano, perché il pericolo proviene da uno strumento che installi proprio per la sicurezza. Quando esegui npx skills add ... o installi un’estensione, scarichi codice di qualcun altro, che l’agente poi esegue con i tuoi permessi. Se l’autore è stato hackerato o il pacchetto era malevolo fin dall’inizio, hai un problema.

Prendi la raccolta di competenze della sezione precedente. Il suo nome include «Anthropic», cosa che induce ad abbassare la guardia. Ma la sua descrizione dichiara chiaramente:

In altre parole, il nome è fuorviante. La raccolta è attualmente matura e pulita, ma il principio resta: la installi a tuo rischio. E la minaccia non è teorica. Nel maggio 2026, un’estensione malevola per editor è rimasta nel marketplace appena 18 minuti e in quel tempo è riuscita a rubare password dai gestori di password, token GitHub, accessi cloud e persino configurazioni di Claude Code delle persone che l’avevano installata. Un altro dettaglio sgradevole: malware di questo tipo spesso sopravvive alla normale rimozione del pacchetto e si riattiva nella sessione successiva.

Ho sviluppato una semplice abitudine e la consiglio anche a te: prima di installare qualsiasi competenza da GitHub, controllala personalmente. Gli autori possono essere hackerati, gli account dirottati e il malware può finire in un repository. Controllare è la tua salvaguardia.

Il minimo pratico prima dell’installazione: guarda l’autore e il numero di stelle, leggi la descrizione della competenza, non installare uno strumento «perché è stato consigliato in un post» e, se è uno strumento che non conosci, provalo prima in un ambiente di test separato, non su una macchina con chiavi di produzione.

Cosa ti salverà dopo una violazione: backup e ripristino#

La sicurezza non riguarda solo il «tenere fuori gli estranei», ma anche il «tornare alla normalità quando qualcosa va storto». Perché qualcosa andrà storto. Nel caso pratico descritto, un agente AI ha cancellato un database attivo in un progetto di produzione mentre svolgeva un’attività di routine. C’era un backup, ma aveva tre giorni e sono andati persi tre giorni di dati.

Da qui derivano due regole.

Fai spesso i backup. Se la tua app contiene dati che ti dispiacerebbe perdere, una copia ogni tre giorni è un’illusione di protezione. Imposta backup automatici almeno ogni 30 minuti. Per la maggior parte dei database, incluso Supabase, bastano un paio di clic per attivarli.

Git è un’assicurazione contro l’agente. Git conserva la cronologia del codice: puoi ripristinare qualsiasi stato funzionante. Quando un agente riscrive qualcosa che funzionava, torni all’ultima versione funzionante invece di correggere tutto a mano. Se l’AI ha cancellato o danneggiato il progetto e non sai come recuperarlo, leggi il resoconto separato: cosa fare se l’AI ha cancellato il database. Per proteggerti in anticipo dai danni al progetto, consulta la guida come proteggere Claude Code dai danni.

Checklist di sicurezza prima della pubblicazione#

Segui questo elenco proprio prima della pubblicazione, nell’ordine indicato.

1. Segreti in .env e .env in .gitignore. Niente chiavi nel codice. Nessun file .env in un repository pubblico.

2. Chiavi con permessi minimi. Ogni chiave può fare solo ciò che serve. Le chiavi di produzione sono separate dall’ambiente dell’agente.

3. RLS è attivo su tutte le tabelle con dati degli utenti e le policy di accesso sono configurate.

4. Controlli dei permessi lato server per ogni operazione sui dati. Nascondere un pulsante nell'interfaccia non basta. Hai provato manualmente a cambiare l’id nell’indirizzo.

5. Verifica della firma dei webhook. Ogni gestore di notifiche esterne (pagamenti, moduli) verifica la firma.

6. Limitazione della frequenza per le richieste in entrata e le operazioni costose, così non si possono indovinare le password con la forza bruta né far lievitare la bolletta.

7. L’agente non è in modalità «consenti tutto» su una macchina con chiavi di produzione. La lettura di .env è negata.

8. I backup sono frequenti e verificati: hai davvero provato a ripristinare i dati, invece di credere soltanto che le copie «siano da qualche parte».

9. Il codice è stato controllato con /security-review o con il plugin security-guidance. Le vulnerabilità rilevate sono state corrette.

10. Le competenze e le estensioni di altre persone sono state controllate prima dell’installazione. Non hai installato nulla «alla cieca».

Da dove iniziare oggi#

Non cercare di applicare in una sera tutto ciò che contiene questa guida: finirai per non fare nulla. Oggi occupati dei tre passaggi più importanti:

1. Controlla i segreti. Apri .gitignore, verifica che .env sia elencato e controlla che nel repository pubblico non ci siano chiavi. Se qualcuna è stata divulgata, revocala e creane una nuova.
2. Chiedi informazioni su RLS. Di’ all’agente: «mostra le tabelle in cui RLS è disattivato» e abilita RLS ovunque siano archiviati dati delle persone.
3. Imposta backup frequenti. Così, se qualcosa va storto, perderai minuti invece di giorni.

Poi segui la checklist qui sopra man mano che il tuo progetto cresce e inizia a gestire denaro e dati di altre persone.

Un’ultima cosa. La sicurezza nel vibe coding riguarda la responsabilità del proprietario. Non devi diventare un esperto di sicurezza. L’AI ha creato il tuo prodotto in una sera: ottimo, ma ne sei responsabile. Nella pratica, il livello di base descritto in questa guida è ciò che comporta quella responsabilità.

Per lavorare ancora con i modelli, puoi andare su Ailoot.