File .env esposto — la risposta all'incidente in 30 minuti | Scanthra

Scanthra · 6 min di lettura · Aggiornato Maggio 2026

Perché un file .env esposto è grave

Un file .env di solito contiene:

• Username + password + host del database.
• Chiavi API per Stripe, AWS, SendGrid, Mailgun, OpenAI…
• Segreti di firma JWT e client secret OAuth.
• A volte credenziali admin o "password DEV" usate in fase di seeding.

Scanner internet come Shodan, BinaryEdge e decine di botnet che raccolgono credenziali interrogano continuamente /.env su milioni di host. Se il tuo è pubblico, dai per scontato che sia stato letto. Il costo della rotazione è molto più basso del costo di una violazione.

Passo 1 — Ruota ogni segreto nel file

Apri il file (o il tuo backup) e per ogni voce:

• DB_PASSWORD — cambiala nel tuo database (ALTER USER … WITH PASSWORD … in PostgreSQL, ALTER USER … IDENTIFIED BY … in MySQL), poi aggiorna la configurazione dell'app.
• Chiavi API — per ogni provider, vai alla dashboard → Chiavi API → revoca la chiave trapelata, genera una nuova, aggiorna la configurazione. Stripe, AWS e OpenAI supportano tutti la rotazione live senza interruzioni del servizio.
• JWT / segreti di sessione — ruota, sapendo che questo disconnetterà tutti gli utenti. Pianifica in una finestra a basso traffico se necessario, ma non ritardare di più di qualche ora.
• Credenziali SMTP / mailer — ruota immediatamente; le credenziali SMTP trapelate sono il vettore di spam numero 1.

Usa un password manager o il tuo secrets manager (AWS Secrets Manager, Doppler, 1Password, Bitwarden) per generare i nuovi valori. Non riutilizzare mai nessuno dei vecchi segreti.

Passo 2 — Verifica l'utilizzo delle chiavi trapelate

Prima di dimenticare le vecchie chiavi, controlla se qualcuno le ha usate mentre erano esposte:

• Stripe: Dashboard → Developers → Events. Filtra per la tua vecchia chiave. Cerca addebiti, rimborsi, modifiche all'account che non hai effettuato tu.
• AWS: Cronologia eventi di CloudTrail filtrata per l'access key ID trapelato. Cerca nuovi utenti IAM, nuove istanze EC2, letture S3 di bucket inaspettati, qualsiasi azione iam:* o ec2:RunInstances.
• SendGrid / Mailgun: feed di attività per picchi, aggiunta di nuovi template, cambiamenti di IP.
• Database: log di audit (se abilitati) per query inaspettate; controlla pg_stat_activity per le sessioni attive.

Se trovi qualcosa di sospetto: si tratta di un incidente confermato — escalate, registra tutto, segui il tuo piano di risposta agli incidenti, notifica i clienti se sono coinvolti dati personali. Per le entità in scope NIS2 (direttiva UE sulla cybersecurity), è obbligatorio inviare un'allerta precoce entro 24 ore.

Passo 3 — Blocca il percorso definitivamente

Il file esposto probabilmente si trovava nella root dell'applicazione perché la webroot del framework era di un livello troppo alto. Due livelli di difesa sono meglio di uno:

Sposta il file fuori dalla webroot:

mkdir /etc/myapp
mv /var/www/myapp/.env /etc/myapp/.env
chmod 600 /etc/myapp/.env
chown www-data:www-data /etc/myapp/.env

Aggiorna la tua app per leggere dal nuovo percorso.

E blocca i dotfile sul web server:

# nginx
location ~ /\.(?!well-known) { deny all; return 404; }

# Apache
<FilesMatch "^\.">
  Require all denied
</FilesMatch>

Passo 4 — Assicurati che non accada mai più

• Usa un secrets manager in produzione — AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Il file .env diventa una comodità per lo sviluppatore, non un artefatto di deployment.
• Aggiungi un controllo CI che faccia fallire la build se .env è committato. git secrets, trufflehog o gitleaks fanno tutti questo.
• Aggiungi un pre-commit hook con detect-secrets così i leak non arrivano nemmeno al branch main.
• Ruota periodicamente comunque. Ogni 6 mesi per le chiavi a lunga vita; immediatamente quando un membro del team se ne va.

E la cronologia di Git?

Se .env è mai stato committato in un repository pubblico — anche brevemente, anche anni fa — dai per scontato che i segreti siano trapelati. La ricerca di GitHub e migliaia di sistemi di raccolta dati lo hanno già. git filter-repo riscrive la cronologia, ma devi comunque ruotare i valori, perché esistono copie fuori dal tuo controllo.

La lezione noiosa

Il file .env esposto è uno dei problemi rilevati più comuni da Scanthra in progetti PHP, Laravel, Django, Rails e Node. La causa principale è quasi sempre "Ho seguito un tutorial che metteva .env nella root del progetto e ho dimenticato che il web server serve file statici da lì." Spostare il file di una directory in su — e aggiungere la regola di blocco dei dotfile — chiude l'intera classe di problemi.

Come Scanthra rileva questo problema

Il nostro modulo Hidden Files controlla una whitelist curata di percorsi inclusi .env, .env.local, .env.production, .git/config, /backup.sql, /dump.sql, /wp-config.php.bak e altri. Seguiamo questo con controlli magic-byte (ZIP, gzip, header SQLite) così possiamo distinguere un vero backup da una pagina 404 che per caso restituisce 200.