La checklist di sicurezza del vibe coding, in nove controlli

Stai per mandare a qualcuno l’indirizzo della tua app, e una vocina ti dice che prima dovresti controllare. Così cerchi una checklist di sicurezza del vibe coding e ne trovi una da venticinque voci, scritta da una persona che dà per scontato che tu sappia già cos’è una Content Security Policy.

Ecco la parte che lista dopo lista sbaglia: quasi niente di quello che c’è dentro si può controllare. «Usa password forti» è un consiglio. «Ripulisci il codice morto» è ordine. «Segui il principio del privilegio minimo» è una frase. Nessuna ha un test, quindi nessuna si può finire, e una lista che non puoi finire è una preoccupazione con dei numeri sopra.

Questa ha nove voci. Nove è il numero di cose che chiunque può verificare dall’esterno su un’app dal vivo, senza la tua password, senza il tuo repository e senza il tuo account Supabase. Ognuna ha un test che puoi fare da solo e ogni test torna con un sì o con un no.

Pensala come il giro che un pilota fa attorno a un aereo prima di un volo. È corto, tutto quello che ci sta dentro si vede dalla pista, e non sostituisce niente del libretto di manutenzione. L’ultima sezione di questo articolo parla del libretto.

Cosa deve esserci in una checklist di sicurezza del vibe coding?

Nove domande, e sono le nove che un estraneo potrebbe fare alla tua app questo pomeriggio, che tu abbia controllato o no.

Il nostro scanner di sicurezza gratuito fa tutti e nove su qualsiasi URL dal vivo in circa 20 secondi e senza account, ed è la via più rapida per il primo giro. Legge, non si collega mai e non scrive mai niente. Ogni voce qui sotto resta qualcosa che puoi controllare a mano, e i test sono scritti per intero così che tu possa mettere una riga del nostro rapporto accanto al tuo pannello.

I quattro da fare prima di condividere l’indirizzo

Chiavi segrete, regole del database, file privati e bucket di storage. In questi quattro quello che resta esposto sono i tuoi dati o i tuoi soldi, e tutti e quattro tocca a te sistemarli e non alla tua piattaforma di hosting.

Tre di loro sono gli unici controlli dell’intero gruppo che possono segnalare un risultato critico, e il quarto è quello in cui a restare esposto è ciò che i tuoi utenti hanno caricato. Tra il 12 e il 14 agosto 2026 abbiamo passato tutti e nove i controlli su 30.998 app di vibe coding dal vivo, e le cifre di ogni sezione qui sotto vengono da quel giro.

1. C’è una chiave segreta nel codice che la tua app manda?

Cerca in tutto il tuo progetto sk_, sb_secret_, service_role e AKIA. Una corrispondenza dentro qualsiasi cosa che il browser scarica è il risultato.

Tutto quello che serve alla tua app per girare in un browser arriva in quel browser, quindi arriva anche una chiave che ci sta dentro. Alcune chiavi ci stanno di diritto: una chiave Supabase anon o sb_publishable_ è un indirizzo e non un permesso, e trovarla è corretto. Quali chiavi sono sicure in un frontend e quali no è quella distinzione per intero.

Una chiave segreta è l’altro tipo. Una chiave Supabase sb_secret_ o service_role ignora ogni regola di tabella che tu abbia mai scritto. Una chiave Stripe sk_live_ sposta soldi. Abbiamo trovato una chiave di quella classe su 52 app su 30.998, il che è raro ed è la cosa peggiore di questa lista quando capita. Se la tua è una di quelle, ruotala prima di fare qualsiasi altra cosa: cancellare la chiave dal codice lascia il vecchio valore in funzione.

2. Un estraneo può leggere il tuo database?

In Supabase, apri il Security Advisor. Ogni voce che dice che una tabella è pubblica ma la sicurezza per righe non è attiva è una tabella che risponde a chiunque chieda, e proprio quell’avviso ha un articolo tutto suo.

Row Level Security è la regola che decide, riga per riga, chi può vedere cosa. Senza di lei, la chiave pubblica che sta nella tua app basta per leggere la tabella, e quella chiave sta nel browser di ogni visitatore per progetto.

È il risultato serio più comune dell’intero gruppo: 2.096 delle 3.680 app il cui progetto Supabase ci ha risposto, cioè il 57 %, avevano almeno una tabella che consegnava righe a una richiesta senza nessuno collegato. Attivarla su ogni tabella è la riparazione. L’advisor legge le tue impostazioni e non le risposte del tuo database, quindi chiudi controllando dall’esterno: una tabella può avere l’impostazione attiva e una policy che lascia passare tutti lo stesso.

3. Chiunque può scaricare i tuoi file privati?

Apri tuaapp.com/.env e tuaapp.com/.git/config in una finestra privata. Entrambi dovrebbero rifiutarsi di aprirsi.

Un file .env è ogni chiave che credevi al sicuro sul server, in un elenco semplice, a un indirizzo indovinabile. Una cartella .git è la storia del tuo progetto. Nessuno dei due è fatto per essere servito, e ogni tanto lo sono lo stesso, di solito perché una build ha copiato una cartella che non doveva.

È la cosa più rara che troviamo: 8 app su 30.749. Sono anche cinque secondi di lavoro per escluderla, ed è da lì che arrivano le fughe più dannose quando capita.

4. I tuoi bucket di storage elencano cosa contengono?

In Supabase, apri Storage. Leggi la colonna Public su ogni bucket, poi apri le policy di ogni bucket che contiene qualcosa non destinato a tutti.

Qui succedono due cose diverse ed è facile confonderle. Un bucket pubblico serve qualsiasi file di cui qualcuno conosce già il nome. Un bucket elencabile consegna i nomi, e questo trasforma «qualcuno dovrebbe indovinare» in una directory dei caricamenti dei tuoi utenti. Il nostro controllo testa il secondo, perché è quello che cambia cosa un estraneo può fare davvero.

792 app su 27.269 avevano un bucket che si è elencato davanti a noi senza collegarsi. Cosa ottiene un estraneo da quell’elenco è la versione lunga, e la riparazione è di solito un interruttore più una policy.

I cinque che possono aspettare di avere utenti

Header, source map, i tuoi indirizzi API, il certificato e il dominio. Tre di questi li imposta di solito chi ospita la tua app, e due sono date su un calendario.

Nessuno di loro da solo consegna una riga del tuo database, ed è per questo che stanno nel secondo gruppo. Uno dei cinque vale la pena di anticiparlo se la tua app ha un backend suo, ed è segnalato qui sotto.

5. Gli header di sicurezza del browser sono attivi?

È l’unica voce della lista senza una versione che puoi fare dalla barra degli indirizzi. Una scansione li legge, oppure apri gli strumenti di sviluppo del browser, vai alla scheda Rete, clicchi la prima richiesta e leggi gli header della risposta.

Sono piccole istruzioni al browser: carica questa pagina solo via HTTPS, rifiutati di farti incorniciare da un altro sito, non indovinare i tipi di file. La loro assenza non espone niente di per sé. Toglie protezioni che rendono altri attacchi più difficili.

Quasi nessuno passa questa voce e quasi nessuno può. A 30.756 app su 30.981 ne mancava almeno uno, e su un sottodominio di un builder l’impostazione è della piattaforma. Se puoi fare qualcosa sui tuoi dipende interamente da dove è ospitata la tua app.

6. Il tuo codice sorgente originale è pubblicato?

Apri la tua app dal vivo, apri gli strumenti di sviluppo del browser e guarda il pannello Sources. Se i tuoi file compaiono lì con il codice che hai scritto e i commenti che hai lasciato, le source map sono uscite con la build.

Una source map è una tabella di traduzione che riporta il file compresso che la tua app spedisce a codice leggibile. Gli sviluppatori la usano per fare il debug di un sito dal vivo. Pubblicata su internet, vuol dire che chiunque può leggere la tua app come l’hai scritta.

3.885 app su 30.987 hanno pubblicato le loro. Non è una fuga di per sé, e lo diventa quando il codice contiene qualcosa che davi per scontato nessuno avrebbe letto. Cosa espone una source map pubblicata copre la differenza e l’impostazione di build che la spegne.

7. I tuoi indirizzi API rispondono a un estraneo?

Copia uno degli indirizzi API della tua app dalla scheda Rete, poi aprilo in una finestra privata dove non sei collegato. Guarda cosa torna.

È la voce da anticipare se la tua app ha un backend suo, perché tutto quello che un indirizzo consegna a una richiesta senza login è pubblico, comunque sia fatta la pagina che gli sta davanti. 3.852 app su 30.926 ne avevano almeno uno.

L’impostazione imparentata è CORS, che decide quali altri siti web possono chiamare la tua app dal browser di un visitatore. Un carattere jolly lì va spesso benissimo e ogni tanto no, e quale dei due hai vale la pena leggerlo prima di cambiare qualcosa.

8. Il tuo certificato sta per scadere?

Clicca il lucchetto nella barra degli indirizzi, apri il certificato e leggi la data di «Valido fino al».

Quasi ogni hosting li rinnova da solo e quasi ognuno di loro ci riesce. 32 app su 30.851 avevano un certificato scaduto, in scadenza o non affidabile. Quando fallisce, i visitatori ricevono un avviso del browser a tutta pagina che dice loro che il tuo sito non è sicuro, e la maggior parte se ne va.

9. Il tuo dominio è rinnovato?

Entra dal tuo registrar, leggi la data di scadenza e controlla che il rinnovo automatico sia attivo e che la carta dietro non sia scaduta.

È la voce meno tecnica della lista e l’unica che può togliere la tua app da internet del tutto. 55 app su 30.980 avevano un dominio scaduto o in scadenza. Un nome lasciato scadere può anche essere registrato da qualcun altro, insieme a ogni link che qualcuno ci abbia mai puntato.

Cosa portano le altre checklist che non è un controllo di sicurezza

Backup, monitoraggio degli errori, codice morto e consigli sulle password. Il primo è quello che più probabilmente ti costerà qualcosa, e non è un controllo di sicurezza, perché niente fuori dalla tua app può dire se ne hai uno.

È il motivo onesto per cui manca tra i nove. Uno scanner legge il tuo sito dal vivo; un backup è una copia del tuo database che sta altrove, e nessuno sguardo dall’esterno sulla tua app può dire se esiste, se è aggiornata o se si ripristinerebbe. Sta comunque nella tua lista. Sta nel tipo di lista che si tiene, non in quello che si percorre.

I backup di Supabase dipendono dal tuo piano e restano dentro al tuo account Supabase, il che va benissimo finché il problema non è l’account. Le tre strade verso una copia che è tua espone cosa copre ciascuna.

Se preferisci che succeda senza di te, è quello che fa Reeve Care. Prende una copia del tuo database Supabase con la cadenza fissata dal piano che hai, ogni notte sul livello d’ingresso e fino a quattro volte al giorno su quello più alto, rilegge ogni copia prima che conti come backup, e la mette dove Supabase non arriva. Quanto indietro puoi tornare lo fissa lo stesso piano. Ripristinare è un pulsante, e prende un’istantanea dello stato attuale prima di partire, così premerlo nel panico non può distruggere quello che stavi cercando di salvare. Arrivano anche i file caricati, appena colleghi una credenziale Storage, che viene chiesta a parte perché è l’unica chiave che teniamo capace di scrivere: Supabase non rilascia una chiave di sola lettura per i file. Care parte da €49 al mese per un’app, ed è un prezzo di listino, quindi la pagina dei prezzi è a volte sotto la cifra qui e mai sopra. Come una copia viene presa, controllata e rimessa a posto è disegnato passo per passo sulla pagina dei backup Supabase.

Il resto di quello che portano quelle liste è lavoro vero e non questo lavoro. Il monitoraggio degli errori ti dice quando la tua app si rompe, e quella è gestione. «Togli le dipendenze inutilizzate» è ordine. «Usa password forti» vale per tutto quello a cui ti sei mai collegato.

Ogni quanto devo rifare tutto questo?

Dopo ogni deploy che ha toccato le regole del database, le chiavi o le impostazioni di build. Se suona come la maggior parte dei deploy, di solito lo è, e lì sta il vero problema di una checklist che si percorre una volta sola.

Il giro attorno all’aereo si fa prima di ogni volo proprio per questo. Row Level Security viene spenta a mezzanotte per far caricare una pagina e nessuno la riaccende. Una chiave viene incollata nel frontend per far uscire una funzione prima di una demo. Un bucket viene aperto per un caricamento e resta aperto. Ognuna di queste cose è un martedì normale, e ognuna basta a trasformare un risultato pulito in uno serio.

Reeve Monitor esiste per quel buco. Ripassa tutti e nove i controlli ogni ora su un massimo di tre app, guarda ogni 60 secondi se l’app risponde, ti avvisa il giorno in cui un risultato cambia invece di aspettare che tu guardi, e manda un rapporto mensile in lingua semplice. Costa €12 al mese di listino, con sette giorni gratis prima che addebiti, e la pagina dei prezzi è a volte sotto la cifra qui e mai sopra. Monitor sorveglia e nient’altro. I backup sono il piano Care sopra di lui, e Care tiene una copia di un database Supabase e di nient’altro.

Cosa non dimostra niente di tutto questo

Che la tua app è sicura. Nove controlli che tornano puliti vogliono dire che nove domande poste dall’esterno sono tornate pulite il giorno in cui le hai poste.

Quattro cose restano invisibili a ogni voce di questa lista, perché nessuna lascia mai il tuo server. Il tuo codice server, comprese le funzioni di database e le edge function che nessuno da fuori può leggere. Le variabili d’ambiente che hai tenuto fuori dal browser, che è esattamente il loro posto e anche il motivo per cui una scansione non può confermare che siano conservate bene. La tua storia delle versioni, dove una chiave che hai committato a marzo e tolto ad aprile è ancora seduta. E la logica della tua app, per esempio se un utente collegato può aprire l’ordine di un altro cambiando un numero nell’indirizzo.

Cosa una scansione per URL può vedere e cosa no percorre quel confine per bene, comprese le tre strumentazioni che leggono cose diverse e il punto in cui ognuna è cieca.

Cosa fare adesso

Se la tua app tiene i suoi dati in Supabase, la versione scritta attorno a quell’unico stack è la guida alle app Supabase. E se preferisci qualcosa da spuntare invece che da leggere, la checklist di sicurezza in 10 minuti è quella interattiva.