Il tuo file .env è esposto? I dodici percorsi da provare

Qualcuno ti ha detto che il tuo file .env è esposto, e dalla frase non capisci se sia grave. Copre due situazioni completamente diverse. Una è lo strumento che funziona come deve. L’altra significa che un file che credevi privato si scarica dal tuo sito online, da chiunque, da quando sta lì.

Ecco la parte che guida dopo guida mette insieme: un valore del tuo .env che finisce dentro il tuo JavaScript non è lo stesso fatto del file .env servito dal tuo server web. Il primo è il build che fa quello che gli hai chiesto quando hai chiamato la variabile VITE_QUALCOSA. Il secondo è un errore di archiviazione, ed è quello da controllare per primo, perché puoi controllarlo tu da fuori in circa un minuto.

Pensa al tuo sito online come al bancone di un negozio. Tutto quello che sta sul bancone è lì per essere preso: la pagina, le immagini, il JavaScript, il logo. Il retro contiene quello che fa funzionare il negozio, e un visitatore non ha nessuna strada per arrivarci. Un valore compilato dentro il tuo JavaScript è una riga stampata sul volantino sul bancone. Il file .env che risponde a un indirizzo pubblico è la cartella del retro, lasciata sul bancone insieme a tutto il resto.

Il mio file .env è esposto?

Apri il tuo sito online in un browser, aggiungi /.env in fondo all’indirizzo e premi invio.

Possono tornare tre cose, e una sola è un problema.

Una pagina della tua app. La maggior parte dei frontend risponde a ogni indirizzo sconosciuto con la propria pagina indice, perché è così che instrada un’app a pagina singola. Ti esce la home, o la schermata di pagina non trovata. Su quel percorso non viene servito niente.

Un errore. Un 403 o un 404 significa che al server è stato chiesto e ha rifiutato. È la risposta che vuoi.

Testo semplice, con righe dentro. Qualcosa come SUPABASE_URL=https://… e SUPABASE_SERVICE_ROLE_KEY=eyJ…, in un muro monospaziato senza alcuno stile. Il file viene consegnato a chiunque lo chieda, e lo fa dal giorno in cui è stato servito la prima volta.

Due cose diverse si chiamano file .env esposto

Una riguarda il tuo bundle. L’altra riguarda il tuo server.

La prima riga è il caso comune e ha un suo articolo: il prefisso è un’istruzione a pubblicare, e il build l’ha seguita. Tutto quello che segue è la seconda riga.

Perché un’app Lovable non può e una Replit sì

Perché i due host pubblicano cose diverse.

Un builder che fa il deploy di un frontend statico consegna al suo host una cartella di file costruiti: un po’ di HTML, un po’ di JavaScript, qualche immagine. Il tuo .env è stato letto durante il build e in quella cartella non c’è, quindi su /.env non c’è niente da prendere. L’host non potrebbe servire il file nemmeno volendo.

Un’app Replit di solito fa girare un server suo, nella sua cartella di progetto, con i tuoi file accanto al tuo codice. Un server a cui si dice di servire la sua cartella serve ogni file che ci sta dentro, e non ha modo di sapere che uno di quelli contiene le tue chiavi. Lo stesso vale per qualunque cosa tu abbia messo su una macchina tua.

I numeri seguono l’architettura. Su 30.761 app online dove questo controllo ha avuto una risposta, 8 consegnavano almeno un file privato. Sette delle otto erano app Replit, e le app Replit erano 3.025 delle 30.761. L’ottava stava su un dominio suo, cosa che dice lo stesso in un altro modo: qualcuno faceva girare un server proprio.

È il rilievo più raro che stampiamo, e l’unico dei nove senza una spiegazione innocente. Se vuoi la lettura larga di cosa consegnano davvero le app Replit, ne abbiamo scansionate 3.042.

I dodici percorsi da provare

Dodici indirizzi, nell’ordine in cui conviene. Metti ognuno dopo il tuo dominio.

La nostra scansione legge tutti e dodici da fuori e ti nomina quelli che hanno risposto. Prende una ventina di secondi e non chiede un account: scansiona la tua app.

Cosa significa davvero una risposta

Tutto quello che sta in quel file è pubblico adesso, e lo è dal giorno in cui è stato servito la prima volta.

Non scoprirai chi l’ha letto. Un builder non ti dà nessun log di file prelevati che tu possa andare a guardare, e la richiesta somiglia a qualunque altra richiesta per qualunque altro file. Quello di cui puoi essere certo è che qualcuno ci ha provato: ci sono crawler automatici che percorrono esattamente questi dodici indirizzi su tutta internet, senza sosta, e non hanno bisogno di sapere chi sei per trovare il tuo.

Cinque delle otto app che abbiamo trovato consegnavano una delle quattro che costano subito: .env, una directory .git, .aws/credentials o un dump .sql. Le altre tre consegnavano config.json, docker-compose.yml o .npmrc. Quei tre sono quelli che tutti danno per innocui, ed è esattamente il motivo per cui finiscono per contenere token e password di database.

Quello che tutto questo non è, è un verdetto sulla tua app. Un controllo esterno legge cosa il tuo sito consegna a uno sconosciuto, e dodici percorsi che rispondono con niente sono dodici percorsi che rispondono con niente. Cos’altro esce da un’app vibe-coded è l’elenco lungo.

Quello che rovina una settimana: una directory .git

Una directory .git non è un file. È tutta la tua cronologia.

Ogni commit sta lì dentro, compreso quello in cui hai incollato una chiave e quello dopo in cui l’hai tolta. È la parte che la gente capisce male di una fuga .git: cancellare un segreto dal codice che hai oggi non fa niente alla versione in cui c’era ancora, e quella versione sta nella stessa directory che il tuo server pubblica.

Il controllo legge /.git/config e /.git/HEAD perché sono piccoli, il loro contenuto non si confonde, e uno qualsiasi dei due che risponde significa che la directory stessa viene servita. Da lì in poi chi legge non ha bisogno di nessuno strumento speciale. Il formato è documentato e software qualunque lo clona.

Se una chiave è stata in un commit, ruotarla è l’unica cosa che aiuta. Quale venga prima dipende da se la copia è già fuori, e quell’ordine vale la pena azzeccarlo.

Il dump che qualcuno ha lasciato nella cartella

Tre dei dodici percorsi sono dump di database: /database.sql, /dump.sql e /backup.sql.

Un dump è ogni riga di ogni tabella in un file, con lo schema sopra. Indirizzi email, password con hash, ordini, messaggi, qualunque cosa la tua app conservi. Risponde a un indirizzo pubblico per il motivo più noioso di tutto questo articolo: qualcuno ha fatto la cosa responsabile, ha preso una copia del suo database e l’ha salvata nella cartella di progetto in cui si trovava.

Così il file fatto per proteggere i dati è diventato la via più rapida per leggerli tutti. Dove vive una copia è decisione tanto quanto il farla. Tre modi per fare il backup di un database Supabase passa in rassegna le opzioni, e Reeve Care tiene una copia del tuo database Supabase fuori dal tuo server, verificata prima di contare come backup.

Come sistemarlo, e perché l’ordine conta

Togli il file da quello che il tuo server pubblica. Poi ruota ogni segreto che conteneva. In quest’ordine.

Ruotare per primo sembra la metà urgente, ed è la metà che spreca il lavoro. Le tue chiavi nuove vanno nello stesso file, il file risponde ancora allo stesso indirizzo, e hai ruotato dritto dentro la fuga. Niente è più sicuro di dieci minuti fa.

Dove metterlo invece, a seconda di cosa fai girare:

• Un host con un suo archivio di segreti. Replit Secrets, le variabili d’ambiente di una piattaforma, il pannello del tuo hosting. Il valore viene letto dal tuo server a runtime e non sta mai in un file dentro la cartella pubblicata.
• Fuori dalla cartella servita. Se controlli la configurazione del server, puntalo a una cartella di output del build invece che alla radice del progetto. Così un file nella radice non ha nessun indirizzo.
• Nemmeno nel repository, che è un’abitudine a parte e buona. Per il problema di oggi non fa niente.

L’ultimo punto va detto chiaro, perché .gitignore è la risposta a cui tutti si aggrappano. Tiene il file fuori dal tuo repository. Il file sul tuo server ci è finito perché il server sta seduto nella tua cartella di progetto, e git non ha opinioni al riguardo.

Cosa fare adesso

Se preferisci passare la tua app come una lista, la checklist di sicurezza in 10 minuti copre questo insieme alle altre cose da chiudere in un’app appena lanciata.