Reeve La tua app Bolt è sicura?
Costruire su Bolt è sicuro? Il codice è raramente il problema. A decidere è se le tabelle che Bolt ha scritto per te sono mai state chiuse a chiave.
I loghi sono di proprietà dei rispettivi titolari e sono mostrati solo per indicare la compatibilità.
In breve
- Un'app Bolt è di solito sicura sul lato codice. A decidere è se le tabelle generate da Bolt sono mai state chiuse a chiave.
- Le tabelle create eseguendo SQL non ricevono la Row Level Security per impostazione predefinita, ed è scrivendo SQL che Bolt le crea.
- Una chiave pubblicabile nella tua app è corretta. sb_secret_… o service_role che arriva al browser è quella da rigenerare oggi.
Bolt scrive l'intero progetto: le schermate, i collegamenti e le tabelle del database sotto. Proprio quest'ultima parte è quella che non vedi mai, ed è dove comincia davvero quasi ogni storia del tipo «la mia app Bolt perde dati».
Ecco il punto che guida dopo guida racconta male: il codice che Bolt ha scritto è raramente il problema. Il problema è di solito un singolo interruttore per tabella nel tuo database che non è mai stato acceso, per come le tabelle sono state create e non perché qualcuno abbia sbagliato.
Che cosa Bolt consegna a un visitatore e che cosa tiene
Due metà, e solo una è privata.
Pensala come un negozio. Bolt ti costruisce una vetrina (pagine, pulsanti, moduli), e quella vetrina viene consegnata per intero a ogni visitatore che carica il tuo sito. Deve essere così. Un browser non può mostrare una pagina che non gli è stata data, quindi non esiste una versione in cui la facciata della tua app resti segreta. Dietro c'è un magazzino, il tuo database Supabase, un edificio separato con la sua serratura.
Il presupposto che costa caro è che la vetrina comandi il magazzino. Non lo comanda. Il tuo database sta su internet con un proprio indirizzo, e quell'indirizzo è stampato sulla vetrina perché è così che la tua stessa app lo raggiunge. Chiunque legga i tuoi file pubblicati legge anche l'indirizzo, e da lì può parlare con il magazzino senza attraversare mai il tuo negozio.
È un problema che la mia app Bolt contenga una chiave API?
Di solito no. Dipende interamente da quale, e ce ne sono due che si somigliano quasi in tutto.
Una chiave pubblicabile nomina il tuo progetto e nient'altro. Supabase la
chiama sb_publishable_… nei progetti nuovi e anon in quelli più vecchi, ed è
costruita per stare in un browser dove chiunque può leggerla. Una chiave
segreta (sb_secret_…, oppure service_role prima della rinomina) è
l'opposto. Ignora ogni regola tu abbia scritto e legge e scrive ogni riga di ogni
tabella.
Stanno una accanto all'altra nel pannello Supabase, hanno una lunghezza simile e si comportano allo stesso modo mentre costruisci. Non si rompe niente se viene copiata quella sbagliata, ed è proprio per questo che sopravvive fino in produzione. La versione lunga di come distinguerle si legge in circa un minuto.
L'interruttore che decide a chi risponde il tuo database
La Row Level Security è un'impostazione per tabella in Supabase che decide, riga per riga, chi può leggere cosa. Spenta, la tua chiave pubblicabile restituisce l'intera tabella. Accesa, con una policy scritta, restituisce solo le righe che quella policy permette.
E ora la parte che riguarda un progetto Bolt in particolare. Supabase attiva la Row Level Security per impostazione predefinita sulle tabelle create nel Table Editor del pannello, quello a clic. Le tabelle create eseguendo SQL non la ricevono e vanno attivate deliberatamente.
Bolt crea le tue tabelle scrivendo SQL.
Quindi la forma consueta di un progetto Bolt è un insieme di tabelle generate arrivate senza serratura, accanto a ciò che hai aggiunto a mano più tardi, che invece ce l'ha. Le due sono indistinguibili nell'editor ed entrambe funzionano perfettamente. E attivare l'impostazione non è nemmeno il traguardo: una tabella con la Row Level Security accesa e una policy che permette a tutti è aperta mentre si dichiara chiusa.
Come controllare la tua app Bolt in una decina di minuti
Leggi il tuo elenco di policy. In Supabase, Authentication → Policies mostra ogni tabella con lo stato della Row Level Security. Comincia da tutto ciò che risulta disattivato; è leggibile da chiunque abbia l'indirizzo del tuo progetto.
Conferma quale chiave hai spedito. Settings → API in Supabase le mostra entrambe. Quella pubblicabile nella tua app è corretta e non richiede nulla. Se una chiave segreta è mai stata incollata nel progetto, rigenerala lì prima di toccare il codice: cancellare la riga non chiude la porta, perché il valore vecchio sopravvive nelle copie in cache del tuo sito.
Controlla i tuoi bucket di storage. Un bucket contrassegnato come pubblico può essere elencato e scaricato da chiunque, che la tua app rimandi o no ai file che contiene.
E poi guarda da fuori. Tutto quanto sopra ti dice che cosa è configurato. Non ti dice che cosa un estraneo raggiunge davvero, che è un'altra domanda ed è quella che conta. La nostra scansione gratuita legge il tuo sito dal vivo come farebbe qualsiasi visitatore e ti dà un voto in una ventina di secondi, senza account: scansiona la tua app.
Cosa fare
- Tutto ciò che Bolt consegna a un browser è leggibile da chiunque. È così che funzionano i browser, e nasconderlo non è una strada che valga la pena.
- Una chiave pubblicabile nella tua app è corretta. Una chiave segreta (
sb_secret_…oservice_role) è quella da rigenerare oggi. - Le tabelle create eseguendo SQL non ricevono la Row Level Security per impostazione predefinita, ed è scrivendo SQL che Bolt crea le tabelle.
- Attivare l'impostazione è il primo passo. Una policy che permette a tutti lascia la tabella aperta mentre il pannello la mostra come protetta.
- Che la tua app funzioni non è una prova che sia chiusa a chiave. Da dentro i due stati sembrano identici.
Apri Authentication → Policies in Supabase e leggi l'elenco dall'alto in basso. Se qualcosa lì dice che la Row Level Security è disattivata, è da quella tabella che si comincia, e la checklist di sicurezza in 10 minuti copre il resto della superficie una volta fatto.
Cosa può davvero andare storto con un'app Bolt
Niente di tutto questo significa che hai fatto qualcosa di sbagliato: sono i soliti effetti collaterali del costruire in fretta. Ecco cosa vale la pena controllare:
Una chiave segreta che finisce nel browser (la trappola VITE_)
Le app Bolt sono di solito costruite con Vite, che ha una regola che frega le persone: qualsiasi impostazione il cui nome inizia con VITE_ viene incorporata nel codice che gira nel browser del tuo visitatore, dove chiunque può leggerla. Chiama un vero segreto VITE_QUALCOSA e finisce in pubblico. Alcune chiavi devono essere pubbliche (come una chiave «anon» di Supabase), il che va bene: Reeve distingue quelle sicure da quelle pericolose, così niente falsi allarmi.
Il tuo database lasciato aperto (RLS di Supabase disattivato)
Bolt spesso collega la tua app a Supabase per i dati. Supabase ha un interruttore chiamato Row Level Security (RLS) che decide chi può leggere o modificare ogni riga. Se è disattivato, le tue tabelle possono essere leggibili, o modificabili, da chiunque trovi l'indirizzo. È il problema serio più comune nelle app create dall'IA, ed è invisibile a meno che tu non controlli.
Un file .env o di configurazione esposto
Il file .env contiene le chiavi e le password di un progetto. A volte viene pubblicato per sbaglio insieme all'app pubblicata. Se è raggiungibile dall'esterno, è una scorciatoia a tutto ciò che è sensibile. Reeve controlla se il tuo è accessibile senza che tu lo sappia.
Archiviazione di file pubblica
Se le persone caricano file nella tua app, questi vivono in «bucket» di archiviazione. Un bucket lasciato pubblico significa che chiunque può elencare o scaricare ciò che c'è dentro, così un caricamento privato può finire visibile a tutti. Reeve controlla se i tuoi bucket sono elencabili; non scarica mai i file di nessuno.
Source map lasciate attive
Una «source map» è un file di aiuto che rivela il codice originale della tua app. Comoda mentre costruisci, ma se finisce in produzione consegna agli estranei una mappa leggibile di come funziona la tua app, rendendo ogni altra porta più facile da trovare. Bassa urgenza, ma vale la pena sistemarla.
Header di sicurezza mancanti ed endpoint aperti
Piccole impostazioni che dicono ai browser come proteggere i tuoi visitatori, più il fatto che i tuoi endpoint di dati rispondano a chiunque o a qualsiasi sito. Minori da soli; insieme allargano la falla. Reeve segnala quelli che mancano.
Cos'è Reeve, e cosa non è
Reeve è un controllo gratuito, in sola lettura, dall'esterno, come un ispettore che gira attorno all'edificio e prova le porte. È 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.
Bolt e StackBlitz continuano a migliorare ciò che viene generato, e se la tua app usa Supabase, il consulente di Supabase segnala i problemi del database nella sua dashboard. Entrambi aiutano. Cosa aggiunge Reeve: tu vivi in Bolt, non in una dashboard, e quegli strumenti parlano da sviluppatori. Reeve guarda tutta la tua app pubblicata dall'esterno, come farebbe un estraneo, e ti dice ciò che trova con parole su cui puoi agire. 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
La mia app Bolt è sicura per impostazione predefinita?
Bolt ti dà rapidamente un'app funzionante, ma «sicura per impostazione predefinita» dipende da come è collegata, soprattutto dalle tue variabili d'ambiente e, se usi Supabase, dalle regole del tuo database. L'unico modo di saperlo è controllare cosa è davvero esposto, ed è ciò che Reeve fa gratis in circa 20 secondi.
Perché la mia chiave di API è trapelata in un'app Bolt?
Di solito perché era conservata in un'impostazione che inizia con VITE_. Vite le incorpora di proposito nel bundle del browser, così qualsiasi segreto chiamato in quel modo diventa pubblico. Reeve legge il codice caricato della tua app, trova le chiavi e ti dice quali sono sicure da esporre e quali vanno spostate sul server.
Bolt usa Supabase, ed è sicuro?
Bolt collega spesso le app a Supabase. Supabase è sicuro quando la Row Level Security è attiva e solo la tua chiave pubblica «anon» è nel front-end. Se l'RLS è disattivato o una chiave «service_role» è trapelata, i tuoi dati possono essere esposti. Reeve controlla entrambi senza mai leggere i tuoi dati reali.
Scansionare la mia app Bolt cambierà qualcosa?
No. Reeve guarda solo ciò che è già pubblico dall'esterno. Non accede mai, non cambia mai nulla e non scarica mai i tuoi file. In sola lettura, come controllare se una porta è chiusa a chiave senza entrare.
Bolt ha scritto le mie tabelle. Sono chiuse a chiave per impostazione predefinita?
Spesso no, e il motivo è meccanico. Supabase attiva la Row Level Security automaticamente per le tabelle che crei cliccando nel Table Editor, ma non per quelle create eseguendo SQL. Un builder crea le tabelle eseguendo SQL, quindi quelle tabelle arrivano con l'interruttore spento, a meno che qualcosa non lo abbia acceso dopo.
L'anteprima funzionava e l'app pubblicata funziona. Vuol dire che è configurata bene?
No, perché entrambe funzionerebbero in ogni caso. Un'app senza regole sul suo database si comporta esattamente come una con le regole giuste, fino al momento in cui qualcuno interroga il database direttamente invece di passare dalle tue schermate. Funzionare non è la stessa prova di essere protetti.
Dove guardo per sapere se il mio progetto Bolt ha questo problema?
Apri il tuo progetto Supabase e vai su Authentication, poi Policies. Lì è elencata ogni tabella dello schema public con lo stato della Row Level Security. Qualunque tabella risulti disattivata può essere letta da chiunque possieda l'indirizzo del tuo progetto e la tua chiave pubblicabile, e sono entrambi dentro l'app che hai pubblicato.