Fichiers exposés
Les chemins que PostShip sonde à la racine de votre site (.env, .git, sauvegardes, phpinfo) et comment il évite le faux positif de la SPA.
Mis à jour le 11 septembre 2026
Sur cette page
- Ce que PostShip vérifie
- Pourquoi le statut ne suffit pas
- robots.txt qui en dit trop
- Le score
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- Pourquoi mon site en SPA passe-t-il alors que /.env répond 200 ?
- Pourquoi un fichier que je sais présent n'est-il pas signalé ?
- Pourquoi ne pas sonder security.txt ?
Un .env avec la clé Stripe, un .git/ complet qu'on peut cloner, une sauvegarde backup.sql de la base clients, un phpinfo.php oublié d'un débogage : rien de tout ça n'est une faille du code. C'est un fichier au mauvais endroit, servi par un serveur qui sert tout ce qu'on lui demande. Ça arrive au déploiement, à la migration, et personne ne le voit : le site marche exactement pareil. Les scanners automatiques, eux, passent sur ces chemins toutes les heures. Ce contrôle y passe avant eux, à chaque déploiement.
Ce que PostShip vérifie
Depuis l'origine du site, pas depuis l'URL complète : un .env traîne à la racine du serveur, pas sous /fr/accueil. PostShip demande d'abord /robots.txt (le témoin que l'origine répond, et une lecture utile de toute façon), puis les chemins ci-dessous, du plus grave au moins grave. Si le budget de requêtes coupe la liste, c'est la fin qu'on perd, pas le .env. Six requêtes de front : assez pour tenir dans le délai, pas assez pour ressembler à un scan hostile pour votre pare-feu.
| Chemin sondé | Code levé | Ce qui confirme |
|---|---|---|
/.env | env_expose | Une ligne CLE=valeur en majuscules |
/.git/config, /.git/HEAD | git_expose | [core] ou [remote, ou ref: refs/ |
/wp-config.php.bak, .php~, .php.old | config_expose | DB_PASSWORD ou DB_NAME |
/phpinfo.php, /info.php | phpinfo_expose | PHP Version ou phpinfo() |
/backup.zip, /site.zip | sauvegarde_exposee | La signature d'un zip (PK) |
/backup.tar.gz | sauvegarde_exposee | La signature d'un gzip |
/backup.sql, /dump.sql, /db.sql | sauvegarde_exposee | CREATE TABLE ou INSERT INTO |
/.htpasswd | htpasswd_expose | Une ligne utilisateur:$hash |
/.DS_Store | ds_store_expose | L'en-tête binaire du fichier |
/server-status | server_status_expose | Apache Server Status |
Pourquoi le statut ne suffit pas
Le piège de ce contrôle, c'est le site qui répond 200 à tout : une application monopage dont le serveur renvoie index.html pour n'importe quel chemin inconnu. Sur un tel site, /.env répond 200 — et ne contient rien. Le statut ne prouve donc rien ; c'est le contenu qui fait foi. Chaque chemin a une signature (quelques octets ou une ligne caractéristique) sans laquelle un 200 ne compte pas. PostShip ne lit que les 16 premiers Ko d'un corps : toutes les signatures tiennent dans les premières lignes, et lire plus reviendrait à télécharger la sauvegarde qu'on cherche justement à ne pas voir circuler.
Un 403 est une protection (tant mieux), un 404 une absence, une redirection une réponse d'ailleurs : dans les trois cas, le corps n'est pas lu. Le chemin est rapporté, jamais le contenu.
robots.txt qui en dit trop
Un robots.txt n'est jamais un manque, mais il peut trop en dire. Interdire /backup aux robots, c'est dire à tout le monde qu'il y a un /backup : le fichier est lu par les scanners bien avant les robots. Une directive Disallow: qui commence par /admin, /backup ou /.git lève l'avertissement robots_revele_des_chemins. Pas /wp-admin : WordPress l'écrit lui-même par défaut, et le chemin n'est un secret pour personne.
Le score
100 points, moins 30 par manque et 5 par avertissement, plancher à 0. Un .env en ligne est un incident ; un robots.txt bavard est un conseil.
Régler
Rien à configurer : la cible est créée par PostShip pour chaque projet, hors quota d'URLs. Projet → Santé → Contrôles du site → Fichiers exposés pour lire le verdict, les chemins trouvés et le score. Le contrôle se désactive depuis la même carte.
Il tourne au déploiement (webhook, T+2 / T+8, « Lancer maintenant »), comme les autres contrôles du site.
Ce qui déclenche une alerte
Un fail — au moins un fichier confirmé — après les confirmations de vos règles. L'alerte porte la phrase du code : « Le fichier .env est lisible depuis le web : vos secrets sont publics, révoquez-les. », « Le dossier .git est lisible depuis le web : tout votre code source est téléchargeable. »
Ce qui ne sonne pas : l'avertissement sur le robots.txt ; une origine qui ne répond pas du tout (le contrôle est en error, et le contrôle HTTP dira la même chose) ; un budget épuisé avant la première requête (« reporté au prochain passage »). Ce qui n'a pas été testé n'est jamais déclaré absent : ce serait une conclusion sans requête.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Verdict et score à l'écran | Oui | Oui | Oui |
| Alerte sur un fichier exposé | Non | Oui | Oui |
Voir les plans.
Dépannage
Pourquoi mon site en SPA passe-t-il alors que /.env répond 200 ?
Parce que ce 200 renvoie votre index.html, pas un fichier dotenv. C'est exactement le cas que la signature existe pour écarter. Le contrôle échouerait si la réponse contenait une ligne CLE=valeur.
Pourquoi un fichier que je sais présent n'est-il pas signalé ?
Trois raisons possibles : il redirige (PostShip ne lit pas le corps d'une redirection), sa signature n'est pas reconnue (un .env sans aucune ligne en majuscules, un dump sans CREATE TABLE), ou le budget du passage s'est épuisé avant son tour — le détail dit alors combien de chemins ont été testés.
Pourquoi ne pas sonder security.txt ?
Son absence est la norme (quelques pour cent des sites en ont un), et un avertissement présent sur presque chaque projet finit par masquer les vrais.