Vibe Coding e Sicurezza: Autenticazione, Segreti, Vulnerabilità e Codice Morto

La Sicurezza è Dove il Vibe Coding Fa Più Male

Questo è il terzo articolo della collana Da Vibe Coding a Produzione. Saliamo ai Livelli 2, 3, 4 e 5 della piramide, quelli che riguardano la sicurezza, ed è qui che il vibe coding ti espone di più.

Il motivo è semplice: la sicurezza non si vede. Un'app insicura funziona esattamente come una sicura, finché qualcuno non ne approfitta. E quando succede, il prezzo lo paga il fondatore. Questi sono i quattro controlli che devi superare prima di andare in produzione.

Livello 2: Autenticazione - Non Scriverla da Solo

Uno degli errori più comuni nel vibe coding è trascinarsi un modulo di autenticazione completamente custom, scritto da zero. È un errore perché l'autenticazione è uno di quei pezzi dove non devi reinventare la ruota.

Gestire login, sessioni, reset password e protezione dagli attacchi nel modo giusto è difficile, ed esistono soluzioni mature che lo fanno per te. Se vuoi un servizio gestito da terze parti, Clerk è un'ottima scelta. Se preferisci tenere l'autenticazione dentro la tua applicazione, Auth.js fa il lavoro.

Affidarti a queste soluzioni ti protegge da un'intera categoria di vulnerabilità: login bucati, sessioni gestite male, account compromessi. È uno dei pochi casi in cui la cosa più professionale che puoi fare è non scrivere codice.

Autorizzazione e RLS: Quando un Utente Vede i Dati di un Altro

L'autenticazione risponde a "chi sei". Ma c'è una seconda domanda, altrettanto critica e quasi sempre dimenticata nel vibe coding: "cosa puoi vedere?". È l'autorizzazione, e il suo cuore è la Row Level Security (RLS), cioè la visibilità a livello di singolo record e, nei casi più delicati, a livello di campo.

Il problema tipico è questo: l'app non ha una gerarchia di ruoli, o non ha proprio il concetto di ruolo. La visibilità dei dati viene gestita con una sequenza di if sparsi nel codice, aggiunti man mano che servono, perché lo startupper medio non ha in testa il concetto di "ambito di visibilità". Funziona finché c'è un utente solo. Poi arriva il secondo, e scopri che vede i dati del primo.

La RLS impostata bene fa sì che la regola di "chi vede cosa" viva a livello di dato, non in decine di condizioni sparse che nessuno riesce più a tenere insieme. Significa definire i ruoli e la separazione degli ambiti fin dall'inizio, e applicare la visibilità sul record (e sul campo) in modo centralizzato.

Il guaio è che tutto questo si scopre quasi sempre dopo. E rifarlo a posteriori, quando l'app è già piena di if e non ha un modello di ruoli, non è una patch: è una riscrittura, con un debito tecnico enorme. È uno di quei livelli dove pagare la fondazione all'inizio costa una frazione di quello che costa rifarla dopo.

Livello 3: Segreti e File .env - Dove l'Errore Diventa una Bolletta

Questo è l'errore che non vedi subito. Te ne accorgi solo dopo, quando ti arriva una bolletta che ti fa bruciare l'intero account OpenAI in una notte.

Sempre più spesso i tecnici poco esperti mettono i file di ambiente in percorsi esposti al pubblico, con dentro chiavi API e token che finiscono indicizzati sul web. Una volta esposta, una chiave è compromessa, punto: non basta cancellare il file, va revocata e rigenerata.

L'ideale non è nemmeno avere un file .env: è avere una struttura che salva tutte le variabili dentro l'ambiente o un secret manager, in modo che non esista un punto fisico da rubare. Aggiungi una rotazione periodica dei token e riduci drasticamente la superficie attaccabile dall'esterno.

Livello 4: Dipendenze e Vulnerabilità - Il Controllo Obbligatorio

Questa è la parte più critica e, non a caso, quella più spesso ignorata. Non è un raffinamento: è un'attività obbligatoria prima di andare in produzione.

L'AI non ti scrive solo il codice. Ti porta anche le dipendenze, cioè le librerie su cui la tua app si appoggia. E qui c'è un problema strutturale: i modelli sono addestrati su versioni vecchie, quindi tendono a suggerirti librerie potenzialmente obsolete o deprecate, a volte con vulnerabilità già note e pubblicate.

Per questo la prima vulnerabilità da controllare sono proprio le dipendenze e il codice deprecato. Strumenti come Dependabot di GitHub ti avvisano in automatico quando una libreria ha una falla nota e ti propongono l'aggiornamento. È un controllo che l'AI media non fa al posto tuo: tu devi saperlo e attivarlo.

Livello 5: Codice Morto - la Falla che Nessuno Manutiene

Il codice morto sembra un problema di ordine e pulizia. In realtà è un problema di sicurezza, ed è per questo che lo trattiamo qui.

Il vibe coding lascia spesso dietro di sé codice morto: funzioni mai chiamate, endpoint dimenticati, logiche abbandonate, pezzi che non servono più. Ogni riga di codice morto allarga la superficie d'attacco della tua app, perché fa parte di logiche che nessuno mantiene più e che possono nascondere falle che nessuno controlla.

C'è poi un punto pratico: quando l'applicazione diventa grande, gli agenti AI non riescono più a vedere tutto il codice morto presente. Più cresce il progetto, più aumenta il valore di un controllo umano, di un esperto che sa cosa cercare ed eliminare. Tenere la codebase pulita non è estetica: è ridurre i punti da cui ti possono attaccare. Ne abbiamo parlato anche nella guida su come usare l'AI senza creare debito tecnico.

La Sicurezza Non è un Optional

Autenticazione, segreti, dipendenze e codice morto non sono dettagli da sistemare dopo il lancio. Sono la base che decide se la tua app può ospitare utenti veri e dati reali senza diventare un problema.

In Castaldo Solutions questa è la parte di hardening che facciamo più spesso sugli MVP costruiti dai fondatori: prendiamo qualcosa che funziona e lo rendiamo sicuro prima di esporlo al mondo.

Nel prossimo articolo saliamo al Livello 6 e affrontiamo la compliance come processo: AI Act, Legge 132/2025, sanzioni e perché la conformità va progettata fin dall'inizio.

Richiedi un check di sicurezza prima di andare in produzione.