Fichiers .env, .git et sauvegardes exposés : comment les secrets fuient des sites web

Certaines des fuites les plus graves sur un site web ne demandent aucun piratage. Un fichier qui n'aurait jamais dû être accessible se trouve à la racine du site, le serveur l'envoie sans broncher à quiconque le demande, et ce fichier contient un mot de passe de base de données, une clé d'API ou le code source complet du site.

Les 3 suspects habituels sont les fichiers .env contenant des secrets de configuration, les dossiers .git qui renferment tout l'historique du dépôt, et les copies de sauvegarde comme site.zip, db.sql ou config.php.bak. L'OWASP Web Security Testing Guide les cite tous comme des sources typiques d'identifiants et de code source exposés.

Vous pouvez vérifier votre propre site en quelques minutes avec curl.

Comment ces fichiers deviennent accessibles

• Les fichiers .env. De nombreux frameworks lisent leurs secrets dans un fichier .env placé dans le dossier du projet. Si la racine documentaire du serveur web est le dossier du projet au lieu de son sous-dossier public, le fichier est servi comme n'importe quel autre.
• Les dossiers .git. Déployer en lançant git clone ou git pull directement dans la racine du site laisse le répertoire .git à côté du site. Avec lui, on peut reconstituer le code source et chaque commit passé, y compris des secrets « supprimés » depuis longtemps.
• Les sauvegardes et exports. Un zip rapide avant une mise à jour, un export db.sql pour une migration, une copie d'éditeur comme index.php~ ou config.php.old. L'OWASP note qu'une sauvegarde de script peut être servie en texte brut au lieu d'être exécutée, ce qui révèle son code source.
• Les restes d'outils. phpinfo.php, .htpasswd, .DS_Store, les fichiers d'état Terraform et les fichiers journaux apparaissent de la même façon.

Le point commun : modifier ou déployer directement sur le serveur de production, sans étape qui décide de ce qui a sa place dans la racine du site.

Comment vérifier votre propre site

Demandez les chemins les plus courants et regardez le code de statut et la taille de chaque réponse :

for p in .env .git/HEAD .git/config backup.zip site.zip db.sql \
         dump.sql config.php.bak wp-config.php.bak phpinfo.php .DS_Store; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}\n' "https://yourcompany.com/$p"
done

Comment lire les résultats :

• 404 ou 403 pour chaque chemin, c'est ce que vous voulez.
• 200 avec un vrai contenu, c'est un constat. Pour .git/HEAD, un vrai contenu ressemble à ref: refs/heads/main. Pour .env, à des lignes NAME=value.
• 200 avec votre page d'accueil habituelle ou une page d'erreur personnalisée, c'est généralement un « soft 404 ». L'OWASP prévient qu'une simple réponse ne constitue pas un constat : ouvrez-la et confirmez ce qu'elle contient réellement.

Répétez la vérification sur chaque nom d'hôte que vous exploitez, y compris la préproduction et les anciens sous-domaines. C'est là que ces fichiers survivent le plus longtemps, comme décrit dans notre article sur les serveurs de préproduction et de test oubliés. Les archives du web peuvent aussi conserver des copies de fichiers accessibles par le passé : un fichier que vous venez de supprimer a donc peut-être déjà été vu.

Si un secret a été exposé, changez-le d'abord

Supprimer le fichier stoppe les nouveaux téléchargements, mais vous ne pouvez pas savoir qui l'a déjà copié. Considérez chaque secret d'un fichier exposé comme compromis :

1. Changez ou révoquez chaque mot de passe, clé d'API et jeton du fichier. Le guide de GitHub sur la suppression des données sensibles donne le même ordre : révoquer ou changer le secret d'abord, nettoyer l'historique ensuite.
2. Supprimez le fichier du serveur et de tout dossier de sauvegarde situé dans la racine du site.
3. Examinez les journaux d'accès à la recherche de requêtes vers ce chemin, pour comprendre si et quand il a été téléchargé.
4. Vérifiez ce que la clé permettait d'atteindre : consoles cloud, prestataires de paiement, services de messagerie, et cherchez toute activité inexpliquée.

Si des secrets ont été commités dans un dépôt, réécrire l'historique (GitHub recommande git-filter-repo) n'aide qu'une fois que le secret lui-même n'est plus valide.

Comment l'éviter

• Faites pointer la racine documentaire uniquement vers le dossier public, jamais vers la racine du projet.
• Déployez des artefacts de build, pas des copies de travail. Un pipeline CI qui ne copie que les fichiers nécessaires au site écarte .git et .env par construction.
• Bloquez les fichiers cachés au niveau du serveur web, comme indiqué ci-dessous.
• Sortez les secrets des fichiers quand c'est possible : utilisez les variables d'environnement de votre plateforme ou un gestionnaire de secrets.
• Ne stockez jamais de sauvegardes ni d'exports dans la racine du site. L'OWASP recommande de garder données, journaux et fichiers de configuration là où le serveur web ne peut pas les servir.
• Revérifiez après chaque changement d'infrastructure, y compris l'ajout de serveurs derrière un répartiteur de charge.

Bloquer les fichiers cachés (en conservant /.well-known/, nécessaire au renouvellement des certificats) se présente ainsi dans nginx :

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

Et ainsi dans la configuration d'un site Apache :

RedirectMatch 404 /\.(?!well-known)

Une courte liste de contrôle

• Lancez la boucle curl ci-dessus sur chaque nom d'hôte que vous possédez.
• Confirmez chaque 200 en lisant le contenu.
• Changez tout secret qui a été un jour accessible.
• Bloquez les fichiers cachés et les extensions de sauvegarde dans la configuration du serveur web.
• Passez à un pipeline de déploiement qui ne livre que des fichiers construits.

Puisque vous êtes dans la configuration du serveur, c'est le bon moment pour ajouter les en-têtes de sécurité HTTP que tout site d'entreprise devrait envoyer.

Comment Datahorses vous aide

Datahorses surveille votre site web depuis l'extérieur, comme un attaquant le regarderait, et signale les fichiers .git, .env, de sauvegarde et de configuration exposés que les archives du web ont enregistrés sur vos domaines. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès ; votre développeur reçoit les étapes précises pour supprimer le fichier et changer ce qui a fuité. Voir comment nous surveillons et pourquoi aucun accès n'est nécessaire.