Vibe coding: i 6 errori di sicurezza più comuni

Con assistenti come Cursor, Lovable, Bolt, Replit o Copilot si costruisce un’applicazione funzionante in pochi giorni, spesso senza scrivere a mano una riga di codice. È il cosiddetto vibe coding: si descrive cosa si vuole, si accetta il risultato, si itera finché funziona. Il problema è che “funziona” e “è sicura” sono due cose diverse, e l’assistente ottimizza per la prima. Questi sono gli errori che troviamo più spesso.

1. Chiavi e segreti nel codice

Chiavi API, password del database, token dei servizi di pagamento o del provider AI inseriti direttamente nel codice, spesso nella parte che gira nel browser. Chiunque apra gli strumenti per sviluppatori può leggerli e usarli a vostre spese. Come evitarlo: i segreti stanno solo sul server, in variabili d’ambiente, e le chiavi esposte vanno revocate e rigenerate.

2. Autorizzazioni solo nell’interfaccia

Il pulsante “Amministrazione” compare solo agli amministratori, ma l’API che esegue le operazioni non controlla chi la chiama. Oppure basta cambiare un numero nell’indirizzo per vedere l’ordine, la fattura o il profilo di un altro utente. Come evitarlo: ogni richiesta al server deve verificare chi è l’utente e se può accedere a quel dato specifico.

3. Database aperti

Servizi come Supabase e Firebase permettono al frontend di parlare direttamente con il database. Senza regole di accesso, o con regole troppo permissive, il database è leggibile, e talvolta scrivibile, da chiunque conosca l’indirizzo del progetto, che è visibile nel codice dell’applicazione. Come evitarlo: abilitare e verificare le regole di sicurezza a livello di riga o di documento, tabella per tabella.

4. API senza controlli

Endpoint che accettano qualsiasi input senza validarlo, che non richiedono autenticazione o che consentono richieste da qualsiasi sito. È la porta d’ingresso per injection, manipolazione dei dati e abusi. Come evitarlo: autenticazione su tutti gli endpoint non pubblici, validazione degli input, configurazione CORS limitata ai propri domini.

5. Dipendenze non verificate

L’assistente aggiunge librerie per risolvere un problema: a volte versioni vecchie e vulnerabili, a volte pacchetti poco noti, in qualche caso nomi inventati che qualcuno ha poi registrato con codice malevolo. Come evitarlo: verificare ogni dipendenza, tenerle aggiornate e controllarle con gli strumenti di audit del gestore di pacchetti.

6. Nessun limite

Niente limiti al numero di richieste, al numero di tentativi di accesso, alla dimensione dei file caricati. Un’applicazione così si può bloccare, o far costare cara se usa servizi a consumo come i modelli AI, con uno script di poche righe. Come evitarlo: rate limiting, blocco dopo tentativi falliti, quote e avvisi sui costi.

Perché l’AI non li evita da sola

Gli assistenti generano codice che soddisfa la richiesta. Se la richiesta è “fai una pagina che mostra gli ordini dell’utente”, il risultato mostrerà gli ordini, ma non è detto che controlli che siano davvero di quell’utente. La sicurezza va chiesta esplicitamente e, soprattutto, verificata: nessuno di questi errori si vede usando l’applicazione, perché tutto funziona.

Come verificarlo

Il modo più efficace è unire una code review mirata ai punti critici (autenticazione, autorizzazioni, segreti, accesso ai dati) con un penetration test dell’applicazione pubblicata. È quello che facciamo nella verifica descritta alla pagina sicurezza delle applicazioni sviluppate con l’AI. Se l’applicazione integra anche un chatbot o un modello linguistico, si aggiunge il test della parte AI: vedi il nostro approfondimento sulla prompt injection.