15 août 2026

.env accessible publiquement : le test en 10 secondes

Un fichier .env contient, par définition, tout ce que tu ne veux surtout pas rendre public : clés API, secrets Stripe, mots de passe de base de données, tokens de service. Le test pour savoir s'il est exposé tient en une requête HTTP. Voici comment le faire toi-même, pourquoi ça arrive si souvent sur les apps générées par IA, et comment s'en protéger définitivement.

Le test en une ligne

Remplace tonsite.com par ton propre domaine et lance :

curl -s https://tonsite.com/.env

Si la réponse contient des lignes du style DATABASE_URL=... ou STRIPE_SECRET_KEY=... plutôt qu'une page 404, c'est une faille critique — tous tes secrets serveur sont accessibles à quiconque connaît l'URL, sans authentification. Vetora teste automatiquement trois variantes courantes : /.env, /.env.local et /.env.production.

Pourquoi ça arrive avec un déploiement rapide

Sur un serveur Node/Express classique servi tel quel, si le répertoire du projet est utilisé directement comme racine publique (par exemple avec express.static('.') au lieu de express.static('public')), tous les fichiers à la racine — y compris .env — deviennent accessibles par leur chemin. Un scaffold généré rapidement pour "juste servir l'app" saute facilement cette distinction entre fichiers publics et fichiers projet.

Sur Next.js, Vite ou la plupart des frameworks modernes, c'est plus rare par défaut (le serveur ne sert que le dossier de build), mais le risque revient dès qu'un export statique custom, un proxy mal configuré, ou un serveur de fichiers générique se retrouve à pointer sur le mauvais dossier.

Le fichier .git expose la même chose, autrement

Même faille, autre porte d'entrée : si /.git/config répond, tout l'historique Git du projet est potentiellement récupérable — y compris d'anciens commits qui contenaient un secret depuis supprimé du code actuel, mais toujours présent dans l'historique :

curl -s https://tonsite.com/.git/config
# si ça répond avec [core] / repositoryformatversion, le dossier .git est exposé

Des outils comme git-dumper automatisent la reconstitution complète du dépôt à partir de là. Un secret commité "par erreur puis retiré au commit suivant" n'est pas vraiment retiré tant que le .git est exposé.

Le correctif

La bonne nouvelle : c'est presque toujours une configuration serveur, pas un problème d'architecture à refaire.

Nginx / Caddy — bloque explicitement les fichiers/dossiers cachés :

# nginx
location ~ /\.(env|git) {
    deny all;
    return 404;
}

Vercel / Netlify — les variables d'environnement définies dans le dashboard ne sont jamais servies comme fichiers statiques ; le risque vient surtout d'un .env committé par erreur dans le dépôt Git déployé, ou d'un dossier public qui inclut la racine du projet.
Dans tous les cas — ajoute .env* à ton .gitignore dès l'initialisation du projet, avant le premier commit — pas après avoir remarqué le problème.

Si un .env a déjà été exposé, corriger la configuration serveur ne suffit pas : fais pivoter tous les secrets qu'il contenait. Il a pu être indexé, mis en cache, ou récupéré avant que tu ne t'en rendes compte.

Ce test ne prend pas plus de temps qu'un scan automatisé — lance un scan Vetora pour vérifier ça et une dizaine d'autres failles fréquentes en une passe.