Renommer un fichier PHP suffit à publier son code source : le piège des sauvegardes en production

Nous copions chaque fichier avant de le modifier en production. La copie s’appelle mesure.php.avant-ville-20260825, elle est posée à côté de l’original, dans le dossier du plugin. Le jour où nous avons demandé cette adresse à un navigateur, le serveur a répondu 200, avec le code source PHP en clair.

Ni permission mal réglée, ni configuration exotique. C’est le comportement normal d’Apache, et il n’a rien de nouveau.

Le serveur ne lit pas le contenu, il lit l’extension

Un serveur web ne se demande pas ce qu’un fichier contient. Il regarde son extension, cherche le gestionnaire associé, et à défaut sert le fichier tel quel avec un type générique. quelquechose.php passe par l’interpréteur. quelquechose.php.avant-ville-20260825 ne se termine pas par .php : c’est du texte, il part comme du texte.

Vous lisez la suite le mardi

Chaque semaine, la lettre reprend une série publique : la valeur, sa date, sa source. Quatre minutes, le mardi matin.

Ne pas remplirAdresse e-mailJe m'inscris

En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.

La conséquence est plus large qu’une convention de nommage maison. .bak, .orig, .old, .save, le ~ que laisse un éditeur, le .swp qu’abandonne une session interrompue : tous relèvent du même mécanisme. N’importe quel fichier de travail oublié dans un dossier servi est une publication, décidée par personne.

Ce qui sort n’est pas anodin. Du code source, c’est la structure interne, les noms d’options, la logique de vérification, et tout ce qu’un développeur pressé a pu écrire en dur un soir de correctif.

L’inventaire qui rassure à tort

Premier réflexe : recenser les copies. La commande de recensement portait une profondeur de trois niveaux de dossiers, choisie sans y penser. Elle a rendu une liste courte, vite traitée, avec le sentiment du travail fini.

Relancée à six niveaux, elle a doublé. La moitié des copies était plus profonde que la limite que nous avions fixée nous-mêmes, dans des sous-dossiers d’inclusion et de modèles.

C’est le défaut classique d’un audit : le paramètre arbitraire qu’on ne remet pas en cause parce qu’il a produit un résultat plausible. Une recherche qui ne trouve rien au-delà de sa propre limite ne prouve rien, elle confirme sa limite. Quand un inventaire de sécurité rend une liste courte, la première chose à vérifier n’est pas la liste, c’est la commande.

Deux correctifs, et un seul est vraiment un correctif

Le premier tient dans le fichier de configuration du dossier servi : une règle qui refuse toute demande dont le nom se termine par ces motifs de sauvegarde, avec ou sans suffixe de date. Effet immédiat, applicable à un parc entier en quelques minutes.

Un point d’attention à ne pas manquer en écrivant ce motif : il ne doit pas mordre sur les extensions légitimes. Une clé de vérification servie en texte à la racine doit continuer de répondre 200, sinon on répare une fuite en cassant l’indexation. Nous l’avons vérifié dans le même passage, avant de considérer la règle comme posée.

Le second correctif est le seul qui règle vraiment le problème : les sauvegardes ne vivent plus dans le dossier servi. Elles sont écrites un cran au-dessus, hors de portée du serveur web, en conservant l’arborescence d’origine pour rester lisibles. Une règle de refus protège des fichiers exposés ; un fichier écrit ailleurs n’est pas exposé. La différence compte le jour où quelqu’un remplace le fichier de configuration du dossier.

Vérifier la correction sans se faire mentir

Reste à prouver que la fuite est fermée. Demander l’adresse et lire le code de retour semble suffisant. Ça ne l’est pas : entre le serveur et nous, il y a un cache de bord qui garde la réponse d’une sonde précédente et ne se vide pas depuis la machine. Un 200 obtenu après nettoyage peut très bien être le 200 d’avant.

La parade : calibrer la sonde sur des cas dont on connaît la réponse. Ici, un fichier de sauvegarde de test posé exprès doit rendre 403, un fichier texte posé à côté doit rendre 200, une adresse qui n’a jamais existé doit rendre 404. Les trois ensemble prouvent que la règle s’applique et que la réponse n’est pas une vieille réponse en conserve. Relevé le 2026-10-19 sur ce site : 403, 200 et 404.

C’est la même exigence que pour n’importe quel instrument : on le calibre sur un cas dont on connaît déjà la réponse avant de lui faire confiance sur un cas qu’on ignore.

Ce que nous en avons tiré

La convention « copie de sécurité avant modification » est bonne, nous la gardons. Ce qui était mauvais, c’est l’endroit : à côté du fichier d’origine, donc dans un dossier dont la fonction est précisément d’être servi au public.

Une habitude d’administration prise sans réfléchir à ce que le serveur en fait finit par publier quelque chose. Ici, notre propre code. La question à se poser avant d’écrire un fichier n’est pas « est-ce que ça gêne ? » mais « est-ce que cet endroit est servi ? ». Les deux réponses ne sont pas dans le même dossier.