Reeve Basi della sicurezza
Scanner di sicurezza per vibe coding: cosa si perde
Uno scanner di sicurezza per vibe coding legge la tua app dal vivo, da fuori. Cosa copre, le quattro cose che non può vedere e come leggere il risultato.
In breve
- Uno scanner di sicurezza per vibe coding legge quello che i browser dei tuoi visitatori già scaricano: il tuo bundle, le tue intestazioni, il tuo certificato e le risposte che il tuo database dà a uno sconosciuto.
- Questo copre proprio la classe di errori più frequenti quando si costruisce con una IA. Non copre nulla di quello che accade sul tuo server.
- Un risultato pulito significa che ogni domanda che la scansione poteva porre da fuori è tornata pulita. Prendilo come un pensiero in meno.
Incolli l’indirizzo della tua app in uno scanner, aspetti una ventina di secondi e torna indietro una lettera. A, forse C. Poi arriva la domanda che conta davvero: vuol dire che la mia app è a posto?
Ecco la parte che quasi tutti gli strumenti di questa categoria ti lasciano capire da solo. Uno scanner di sicurezza per vibe coding legge la tua app dalla strada. Vede quello che vede il browser di un visitatore qualunque, che è tantissimo, e si ferma alla tua porta d’ingresso. Quello che il tuo server fa in privato resta privato anche per lui.
Sapere dove passa quella linea è ciò che rende una scansione utile. Una A ti dice che le porte sulla strada erano chiuse quando abbiamo guardato, e non dice assolutamente nulla sulla stanza che c’è dietro.
Che cos’è uno scanner di sicurezza per vibe coding?
Uno strumento che carica la tua app dal vivo come farebbe un visitatore, e poi legge quello che è tornato indietro.
Gli dai un URL. Non chiede il tuo codice sorgente, il tuo repository, la password del tuo database o un account presso il builder che hai usato. Recupera la tua pagina, lascia girare il JavaScript per vedere il codice che la tua app consegna davvero, legge le intestazioni arrivate con la risposta, guarda il tuo certificato e pone al tuo database e al tuo archivio file qualche domanda che potrebbe porre qualunque sconosciuto.
Poi annota che cosa ha risposto. È tutta qui la forma della cosa, ed è il motivo per cui ci vogliono venti secondi invece di una settimana.
Questa categoria esiste perché le app costruite con Lovable, Bolt, v0, Cursor, Replit, Windsurf e Base44 sbagliano nello stesso ristretto numero di punti, e quasi tutti quei punti si vedono da fuori. Una chiave segreta nel bundle. Una tabella che risponde a uno sconosciuto. Un bucket di storage che elenca il proprio contenuto. Nessuno ha bisogno del tuo sorgente per trovarne uno, perché la tua app li porge a ogni visitatore per costruzione.
Cosa legge davvero una scansione
Cinque superfici, e i tuoi stessi visitatori ne scaricano quattro senza accorgersene.
| Cosa legge | Da dove arriva | Cosa intercetta |
|---|---|---|
| Il tuo bundle JavaScript | I file che un browser scarica per far girare la tua app | Chiavi consegnate al browser, i percorsi API che chiama, i nomi di tabella che usa |
| Le intestazioni di risposta | Arrivano con ogni pagina servita dal tuo hosting | Protezioni del browser assenti, una regola che risponde a richieste da qualunque sito |
| Le risposte del database | La stessa API di progetto che la tua app chiama da sé | Una tabella che consegna righe a una richiesta senza nessuno autenticato |
| I tuoi bucket di storage | La stessa API pubblica di storage con cui la tua app carica | Un bucket che elenca i propri file a uno sconosciuto |
| Certificato e dominio | L’handshake TLS e la registrazione pubblica nel registro | Un certificato prossimo alla scadenza, un dominio prossimo al decadere |
Il bundle è quello che sorprende. Il codice della tua app deve arrivare nel browser prima di poterci girare, quindi ci arriva anche ogni chiave che contiene, insieme ai percorsi API che chiama e spesso ai nomi delle tabelle che legge. Uno scanner preme lo stesso F12 che premerebbe un visitatore curioso. È solo più veloce, e legge tutti i file invece del primo.
La domanda al database è quella che tutti si aspettano invasiva, ed è la cosa più mite dell’elenco. Per scoprire se una tabella è leggibile da sconosciuti, il nostro chiede all’API un conteggio delle righe e legge il numero da un’intestazione di risposta. Un conteggio sopra lo zero significa che quelle righe sono raggiungibili. Non viene mai recuperata una riga, e la chiave con cui chiede è quella pubblicabile già presente nel tuo bundle, che dovrebbe stare lì.
Le quattro cose che una scansione dell’URL non può vedere
Tutto quello che accade sul tuo server, perché niente di tutto ciò viene mai inviato a un browser.
Il tuo codice server. Edge function, route API, funzioni del database, tutto quello che gira dentro Supabase o presso il tuo hosting. Uno scanner può chiamare un endpoint e leggere quello che torna. Non può leggere il codice che lo ha prodotto, quindi un errore che salta fuori solo con certi input resta invisibile.
Le tue variabili d’ambiente. Le chiavi che hai tenuto sul server, che è esattamente il loro posto. Una scansione può dirti che nel tuo bundle non ha trovato un segreto. Non può confermarti che il segreto sia conservato bene, perché non vede mai il posto in cui lo hai messo.
La tua cronologia delle versioni. Una chiave committata a marzo e tolta ad aprile è sparita dalla tua app ed è ancora nel tuo repository. Chiunque possa vedere quel repository può ancora leggerla, e nessuna quantità di sguardi al tuo sito dal vivo la farà emergere.
La logica della tua app. Se un utente autenticato può aprire l’ordine di un altro cambiando un numero nell’indirizzo. Se un modulo accetterà un prezzo mandato dal browser. Sono decisioni che la tua app prende su cosa permettere, e prenderle in castagna richiede di accedere e provare cose, cioè un penetration test.
C’è un quinto limite che appartiene a noi e non alla categoria, e vale la pena conoscerlo prima di leggere uno dei nostri report. Supabase non serve più a una chiave pubblicabile l’elenco delle tabelle di un progetto, quindi uno scanner non ha modo di chiedere come si chiamano le tue tabelle. Il nostro lavora invece con tre fonti: l’indice del progetto sui progetti più vecchi dove risponde ancora, i nomi di tabella che trova nel tuo stesso bundle, e un elenco di ventisei nomi frequenti nelle app in vibe coding. Una tabella aperta con un nome insolito che non compare mai nel tuo codice frontend è una che non raggiungeremo. L’advisor di Supabase la raggiunge, ed è il confronto di due sezioni più in basso.
Una scansione pulita vuol dire che la mia app è sicura?
No. Vuol dire che ogni domanda che la scansione poteva porre da fuori è tornata pulita, ed è una frase più piccola di quanto sembri.
Una parte del motivo sono i quattro punti ciechi qui sopra. L’altra parte è che un controllo può finire in tre modi e solo uno di questi è un superato. Un controllo trova qualcosa. Un controllo chiede e riceve un no chiaro. Oppure un controllo non riceve alcuna risposta, perché la richiesta è scaduta, l’host l’ha rifiutata o la pagina non ha mai finito di caricare.
Quel terzo finale è ciò che decide se ci si può fidare di un report, ed è il più facile da arrotondare in silenzio a un segno di spunta. Il nostro scrive «Impossibile controllare» sulla riga e lascia stare il tuo voto. Un segno di spunta falso sarebbe la cosa più dannosa che questo scanner potrebbe mettere su uno schermo, perché ci agiresti sopra.
È la stessa onestà a rendere i nostri numeri pubblicati meno allarmanti di quanto sembrino a prima vista. Tra il 12 e il 14 agosto 2026 abbiamo fatto girare questi controlli su 30.998 app dal vivo in vibe coding, e il 99% è tornato con almeno un rilievo. Quasi tutto è una riga sola: intestazioni di sicurezza del browser che la piattaforma di hosting non imposta mai e che la maggior parte dei proprietari su un sottodominio di un builder non può attivare da sé. Contarle è corretto. Leggere quel 99% come «quasi tutte le app sono in pericolo» non lo è.
Scansione dell’URL, del repository o l’advisor di Supabase?
Leggono tre cose diverse, quindi la domanda utile è quale di loro può vedere il problema che hai.
| Tipo | Cosa legge | Cosa ti chiede | Dov’è cieco |
|---|---|---|---|
| Scanner di URL | La tua app dal vivo, da fuori | Un URL | Tutto quello che il tuo server tiene per sé |
| Scanner di repository | Il tuo sorgente e la sua cronologia | Accesso al tuo repo | Se quel codice è pubblicato e cosa fanno le tue regole in produzione |
| Supabase Security Advisor | La configurazione di quel progetto | Il tuo account Supabase | Tutto ciò che sta fuori dal progetto: bundle, intestazioni, altri fornitori |
Si sovrappongono molto meno di quanto i nomi lascino pensare. L’advisor di Supabase passa in rassegna il tuo progetto e segnala problemi di configurazione, tra cui tabelle con la Row Level Security impostata male. Una scansione dell’URL legge la conseguenza, cioè se quelle righe stanno arrivando a sconosciuti proprio adesso. I due si separano più spesso di quanto ti aspetteresti, perché attivare l’impostazione non equivale a essere protetti.
Uno scanner di repository è l’unico dei tre che può trovare la chiave che hai cancellato il mese scorso. È anche l’unico che non può dirti se il codice che ha appena letto è quello che hai pubblicato.
Come si legge il voto
La lettera è limitata dal peggiore rilievo del report, quindi un buon punteggio non salva mai un rilievo grave.
Ogni scansione parte da 100. Un rilievo critico costa 40 punti, uno alto 15, uno medio 5, uno basso 1. Poi si posa un tetto sopra l’aritmetica: un rilievo critico limita il voto a D, due lo limitano a F, e un solo rilievo alto lo limita a C. Un’app per il resto in ordine con una sola tabella aperta esce con una D, ed è il comportamento voluto.
Quello che hai fatto bene compare nel report e non ti costa niente. La tua chiave Supabase pubblicabile che sta nel bundle è elencata come corretta, perché è la sua ragione d’essere, e dipingerla di rosso è il modo in cui uno strumento ti insegna a ignorare il rosso.
Cosa fare con il risultato di una scansione
Cosa fare
- Leggi per prime le righe che dicono «Impossibile controllare». Sono le domande ancora aperte, e non sono un superato.
- Lavora per gravità. Un rilievo critico vuol dire che oggi si può arrivare ai tuoi dati; un’intestazione mancante è un’impostazione che nessuno ha attivato.
- Occupati a parte di quello che sta dentro: tieni le chiavi segrete sul server, cerca nella tua cronologia delle versioni le chiavi che hai cancellato, e accedi come utente di prova per vedere fin dove arriva.
- Riscansiona dopo ogni pubblicazione, e ogni volta che qualcuno tocca una regola del database. È il cambiamento di cui niente ti avverte.
- Se la tua app incassa pagamenti o tiene dati sanitari, prima o poi commissiona un penetration test. Un controllo esterno automatico non è un audit, e nessuna assenza di rilievi è una garanzia.
Il nostro scanner di sicurezza per siti gratuito esegue nove controlli in sola lettura su qualunque URL dal vivo, in una ventina di secondi e senza account. Legge, non scrive mai e non accede mai.
Se preferisci passarci prima a mano, la checklist di sicurezza da 10 minuti copre lo stesso terreno nell’ordine in cui vale la pena farlo.
FAQ
Che cos’è uno scanner di sicurezza per vibe coding?
Uno strumento che carica la tua app dal vivo come farebbe un visitatore e legge quello che torna indietro: il JavaScript che la tua app consegna al browser, le intestazioni che il tuo hosting ci aggiunge, il certificato e le risposte che il tuo database e il tuo archivio file danno a una richiesta che arriva da uno sconosciuto. Gli serve un URL e nient’altro. Riporta quello che ha trovato sulla superficie pubblica della tua app, che è proprio dove le app costruite con una IA sbagliano più spesso.
È sicuro scansionare la mia app?
Sì, se lo scanner si limita a leggere. Il nostro fa lo stesso tipo di richieste di un visitatore qualunque, non accede mai, non scrive, non crea e non cancella niente da nessuna parte, e non scarica mai i dati dei tuoi utenti. Per capire se una tabella del database è leggibile chiede un conteggio delle righe e legge il numero, senza recuperare nemmeno una riga. Il traffico è una manciata di richieste, cioè meno di una persona che naviga sul tuo sito per un minuto.
Una scansione ha bisogno del mio codice sorgente o della password del database?
No. Uno scanner di URL lavora interamente da fuori, quindi non c’è nulla da collegare e nessuna credenziale da consegnare. Questo è anche il suo limite: vede solo quello che la tua app mostra già a ogni visitatore. Uno strumento che legge il tuo repository o si collega al tuo account del database vede cose diverse, e l’articolo qui sopra mette i tre a confronto.
Funziona con Lovable, Bolt, Cursor, Replit, v0, Windsurf e Base44?
Sì, e con qualunque altra cosa metta un sito online, perché la scansione guarda quello che è pubblicato e non quello che lo ha scritto. Il builder conta per la riparazione più che per il controllo: sistemare una tabella aperta è una sequenza di clic diversa in Lovable rispetto a Replit, ed è per questo che il testo della correzione nomina il tuo builder.
Cosa non controlla uno scanner di sicurezza?
Tutto quello che resta sul tuo server. Il codice del server e le funzioni del database, le variabili d’ambiente che hai tenuto fuori dal browser, la chiave che hai committato e poi cancellato dal repository, e i bug della tua logica, per esempio un utente autenticato che apre l’ordine di un altro cambiando un numero nell’indirizzo. Trovare quest’ultimo gruppo richiede di accedere e provare cose, e questo è un penetration test e non una scansione.
Uno scanner di sicurezza per vibe coding è gratuito?
Il nostro lo è, almeno per la scansione in sé: ottieni il voto, il punteggio e il numero dei rilievi sullo schermo in circa 20 secondi, senza account, e i rilievi dettagliati con le correzioni dopo aver dato un indirizzo email. I piani a pagamento esistono per quello che una scansione singola non può fare, cioè accorgersi che il mese prossimo qualcosa è cambiato. Un voto è vero nel secondo in cui lo prendi.