Reeve La tua app v0 è sicura?
Costruire con v0 è sicuro? I componenti generati non sono il rischio. Lo sono i collegamenti che aggiungi intorno, e un nome di variabile decide quasi tutto.
I loghi sono di proprietà dei rispettivi titolari e sono mostrati solo per indicare la compatibilità.
In breve
- Un'app v0 si pubblica di solito senza timori; i componenti generati non sono il rischio. Lo sono i collegamenti che aggiungi intorno.
- Qualsiasi variabile chiamata NEXT_PUBLIC_… viene compilata nel JavaScript che i tuoi visitatori scaricano. È giusto per una chiave pubblicabile e sbagliato per una segreta.
- v0 non imposta le regole del tuo database. Su Supabase, le tabelle create eseguendo SQL partono senza Row Level Security.
v0 ti dà componenti: un'interfaccia funzionante, generata e depositata nel tuo progetto. Quello che non ti dà sono i collegamenti dietro: le variabili d'ambiente, il database, le regole su chi può leggere cosa. È in quello spazio che un progetto v0 di solito va storto, e ci va in silenzio.
Ecco il punto che guida dopo guida racconta male: il codice generato non è il rischio. Il rischio è una convenzione di nomi nel tuo file d'ambiente e un'impostazione del database che con v0 non ha nulla a che vedere.
Quale metà di un progetto v0 è pubblica
La metà dell'interfaccia, per intero.
Pensala come un negozio. I componenti che v0 scrive sono la vetrina: ogni pagina, ogni modulo, ogni pulsante, e l'intera vetrina viene consegnata a ogni visitatore che carica il tuo sito. Non c'è modo di aggirarlo; un browser non può disegnare una pagina che non gli è stata inviata. Dietro c'è il magazzino, il tuo database, un edificio separato con la sua serratura.
Ciò che rende particolare un progetto v0 è che le due metà le assembli tu. I componenti arrivano senza sapere nulla delle tue chiavi o delle tue tabelle, quindi ogni decisione su che cosa passa dal magazzino alla vetrina è una decisione che prendi nel tuo progetto, di solito in un unico file pieno di variabili d'ambiente.
Che cosa vuol dire davvero NEXT_PUBLIC_
Vuol dire «metti questo nel browser».
Next.js, per cui v0 genera codice, decide che cosa ricevono i tuoi visitatori
leggendo il nome della variabile. Tutto ciò che si chiama NEXT_PUBLIC_QUALCOSA
viene compilato nel JavaScript che il tuo sito serve. Tutto ciò che non ha quel
prefisso resta sul server. La stessa regola esiste con altri nomi in altri
strumenti (Vite usa un prefisso VITE_ e dichiara apertamente che quei valori
finiscono nel tuo codice sorgente al momento della build), ma l'effetto è
identico: il prefisso pubblica il valore.
È esattamente giusto per un URL di progetto o una chiave pubblicabile. Ed esattamente sbagliato per una segreta.
La trappola ha una forma riconoscibile. Qualcosa nell'interfaccia non riesce a
leggere un valore, quindi si aggiunge il prefisso per far sparire l'errore, e
sparisce: l'app inizia a funzionare. Se il valore era una chiave Supabase
sb_publishable_…, o la più vecchia anon, non c'è nulla di male. Se era
sb_secret_… o service_role, l'errore era il sistema che ti diceva che quel
codice sta su un server, e la rinomina ha pubblicato una chiave che ignora ogni
regola tu abbia impostato.
Distinguere le due richiede
circa un minuto e vale la pena farlo una volta per ogni chiave nel file.
Che cosa decide se degli estranei possono leggere i tuoi dati
Le regole del tuo database, non i tuoi componenti.
Se i tuoi dati sono in Supabase, l'impostazione è la Row Level Security: un interruttore per tabella che decide riga per riga chi può leggere cosa. Spenta, la tua chiave pubblicabile restituisce l'intera tabella a chiunque la chieda. Accesa e con una policy scritta, restituisce solo ciò che la policy permette.
Supabase la attiva per impostazione predefinita sulle tabelle create nel Table Editor del pannello, e non su quelle create eseguendo SQL. Quindi le tabelle che hai fatto nascere cliccando sono di solito protette, e qualunque tabella creata da un file di migrazione potrebbe non esserlo. Dopo sembrano uguali, e funzionano entrambe.
Ne esiste una seconda versione che prende in trappola chi ha fatto tutto giusto: una tabella può avere la Row Level Security attiva e restare aperta a tutti, per via della policy che ha sopra. Attiva e protetta sono due stati diversi.
Come controllare il tuo progetto v0 in una decina di minuti
Leggi il tuo file d'ambiente riga per riga. Ogni variabile con il prefisso
NEXT_PUBLIC_ è pubblicata. Chiediti per ognuna: mi starebbe bene stamparlo in
homepage? Se no, non sta bene con quel prefisso.
Rigenera tutto ciò che non avrebbe mai dovuto trovarsi lì. Nel pannello del tuo fornitore, crea una nuova chiave e revoca la vecchia. Togliere la riga dal codice non chiude la porta, perché il valore vecchio è ancora nella tua cronologia delle versioni e nelle copie in cache del sito.
Controlla le regole delle tue tabelle. In Supabase, Authentication → Policies elenca ogni tabella e se la Row Level Security è attiva. Tutto ciò che è disattivato è leggibile da chiunque abbia l'indirizzo del tuo progetto.
E poi guarda da fuori. I passaggi qui sopra ti dicono che cosa è configurato; non ti dicono che cosa è davvero raggiungibile. La nostra scansione gratuita legge il tuo sito dal vivo come farebbe un visitatore e ti dà un voto in una ventina di secondi, senza account: scansiona la tua app.
Cosa fare
NEXT_PUBLIC_non è una formalità. Compila il valore dentro i file che ogni visitatore scarica.- Aggiungere il prefisso per zittire un errore è il momento di fermarsi e controllare che cosa contenga davvero quel valore.
- Una chiave pubblicabile sta bene nel browser.
sb_secret_…eservice_rolemai. - v0 non imposta le regole del tuo database. Su Supabase, le tabelle create eseguendo SQL partono senza Row Level Security.
- Una tabella con la Row Level Security attiva può comunque essere aperta a tutti. È la policy la parte che decide.
Apri il tuo file d'ambiente e leggi ad alta voce le righe NEXT_PUBLIC_. Se una
di esse contiene qualcosa che non stamperesti in homepage, rigenerala adesso, poi
la checklist di sicurezza in 10 minuti copre che cos'altro valga la
pena disattivare in un progetto appena lanciato.
Cosa può davvero andare storto con un'app v0
Niente di tutto questo è colpa tua: sono i normali effetti collaterali del generare codice in fretta. Ecco cosa vale la pena controllare:
Una chiave segreta in un componente client (la trappola NEXT_PUBLIC_)
v0 costruisce con Next.js, che ha una regola che fa inciampare: qualsiasi cosa chiamata NEXT_PUBLIC_, e qualsiasi chiave scritta direttamente in un componente client, viene inviata al browser, dove chiunque può leggerla. È facile incollare una chiave di API in un componente generato senza accorgersi che ora è pubblica. Alcune chiavi devono essere pubbliche; Reeve le distingue da quelle che non lo devono, così niente falsi allarmi.
Il tuo database lasciato aperto (RLS di Supabase disattivato)
Se la tua app v0 conserva dati (spesso in Supabase), c'è un interruttore chiamato Row Level Security (RLS) che decide chi può leggere o modificare ogni riga. Se è disattivato, le tue tabelle possono essere aperte a chiunque trovi l'indirizzo. È il problema serio più comune nelle app generate e resta invisibile finché non guardi.
Source map pubblicate
Una «source map» rivela il codice originale della tua app a chiunque apra gli strumenti del browser. È utile mentre costruisci, ma se finisce in produzione consegna agli estranei una copia leggibile di come funziona la tua app, e rende ogni altra falla più facile da trovare. Reeve controlla se le tue sono esposte.
Rotte di API aperte
Le app Next.js spesso includono rotte di API: piccoli endpoint che fanno cose come leggere o scrivere dati. Se una è stata generata senza un controllo di autenticazione, può rispondere a chiunque la chiami. Reeve sonda se i tuoi endpoint rispondono agli estranei, senza mai usarli per cambiare nulla.
Un file .env o di configurazione esposto
Il file .env contiene le chiavi di un progetto. Occasionalmente viene pubblicato per errore con l'app pubblicata, e se è raggiungibile è una scorciatoia a tutto ciò che è sensibile. Reeve controlla se il tuo è accessibile senza che tu lo sappia.
Header di sicurezza mancanti e condivisione aperta (CORS)
Piccole impostazioni che dicono ai browser come proteggere i visitatori, e se qualsiasi sito è autorizzato a chiamare i dati della tua app. Minori da soli; insieme allargano la falla. Reeve segnala cosa manca.
Cos'è Reeve, e cosa non è
Reeve è un controllo gratuito, in sola lettura, dall'esterno, come un ispettore che prova le porte senza entrare. È veloce e coglie gli errori comuni ad alto impatto. Non è un audit di sicurezza completo, e un voto pulito non è una garanzia. Significa che le porte ovvie sono chiuse.
v0 e Vercel continuano ad alzare la qualità di ciò che viene generato e pubblicato, e se usi Supabase, il suo consulente segnala i problemi del database nella dashboard. Entrambi aiutano. Cosa aggiunge Reeve: tu lavori in v0, non leggi il codice generato riga per riga, e quegli strumenti parlano da sviluppatori. Reeve guarda l'intera app pubblicata dall'esterno e ti dice ciò che trova con parole semplici. E se preferisci non pensarci, possiamo tenerla d'occhio noi per te.
Vuoi che sia gestito, non solo controllato?
Reeve Care continua a tenere d'occhio la tua app, fa il backup dei tuoi dati e ti aiuta a sistemare le cose quando si rompono, così puoi continuare a creare invece di preoccuparti.
Scopri Reeve CareFAQ
Il codice di v0 è pronto per la produzione ed è sicuro?
v0 produce codice pulito e moderno, ma «sembra pronto per la produzione» non è la stessa cosa di «controllato». La sicurezza dipende da come è collegata l'app: dove vivono le chiavi, se le regole del tuo database sono attive, se gli endpoint sono protetti. Reeve controlla le parti esposte gratis in circa 20 secondi.
Un'app v0 può esporre le mie chiavi di API?
Sì, se una chiave finisce in un componente client o in un'impostazione NEXT_PUBLIC_, Next.js le invia al browser. Non ogni chiave è un problema: alcune devono essere pubbliche. Reeve trova le chiavi nel tuo codice caricato e ti dice quali sono sicure e quali vanno spostate sul server.
Le rotte di API di v0 sono sicure?
Possono esserlo, ma un endpoint generato a volte esce senza un controllo di autenticazione, il che significa che chiunque lo trovi può chiamarlo. Reeve verifica se i tuoi endpoint rispondono agli estranei; controlla solo che la porta si apra, non la attraversa mai.
Scansionare la mia app v0 romperà qualcosa?
No. Reeve guarda solo ciò che è già pubblico dall'esterno. Non accede mai, non cambia mai nulla e non scarica mai dati. In sola lettura, come controllare se una porta è chiusa a chiave senza entrare.
Che cosa fa davvero il prefisso NEXT_PUBLIC_?
Dice a Next.js di compilare quel valore nel JavaScript inviato al browser. Il valore smette di essere un'impostazione lato server e diventa parte dei tuoi file pubblicati, leggibile da qualsiasi visitatore. È giusto per una chiave pubblicabile e sbagliato per una segreta, e il prefisso è l'unica cosa che lo decide.
Ho rinominato una variabile aggiungendo NEXT_PUBLIC_ perché l'app non riusciva a leggerla. È stato un errore?
Dipende interamente da che cosa contiene la variabile. Se era una chiave pubblicabile o un URL di progetto, la rinomina era la correzione giusta. Se era una chiave segreta, l'app non riusciva a leggerla perché non è mai stata pensata per girare nel browser, e la rinomina l'ha pubblicata. Rigenera quella chiave, poi sposta il codice che ne aveva bisogno in una route lato server.
v0 configura le regole del mio database al posto mio?
Da solo no. v0 genera codice di interfaccia; il database e le sue regole li imposti tu, dovunque li ospiti. Se sei su Supabase, la Row Level Security è attiva per impostazione predefinita solo per le tabelle create nel Table Editor del pannello, e spenta per quelle create eseguendo SQL.