En bref : les fichiers de sauvegarde dans le webroot, c'est-à-dire les dumps de base de données (.sql), les archives (.zip, .tar.gz) et les copies de sauvegarde (.bak, .old, ~), peuvent être téléchargés par quiconque connaît ou devine le nom du fichier. Recherchez régulièrement de tels fichiers avec find, déplacez les sauvegardes hors du répertoire public, bloquez les extensions typiques dans le serveur web et vérifiez dans les journaux d'accès s'ils ont déjà été appelés.
La sauvegarde qui devient une fuite
Peu avant une mise à jour, quelqu'un génère rapidement une sauvegarde : backup.zip dans le répertoire principal, à côté de datenbank.sql. La mise à jour réussit, les fichiers restent là. Des mois plus tard, ils y sont encore, avec tout le code, toutes les données clients et les identifiants du site.
Ce schéma compte parmi les constats les plus fréquents lors des audits de serveurs web. Il ne nécessite aucun exploit ni aucune faille dans PHP. Un serveur web diffuse depuis le webroot ce qui s'y trouve, et les archives ou fichiers SQL, il ne les exécute pas, il les propose en téléchargement.
Une archive du site ne contient d'ailleurs pas que des données, mais aussi le code avec sa configuration. Qui la télécharge peut chercher tranquillement des vulnérabilités et connaît les identifiants de la base de données.
Des scanners automatisés recherchent précisément des noms typiques comme backup.zip, site.tar.gz ou dump.sql, souvent combinés avec le nom de domaine ou une date. Qui croit qu'un nom de fichier inhabituel protège sous-estime la systématique de cette recherche.
De quels fichiers parle-t-on
Les fichiers de sauvegarde dans le webroot se présentent sous plusieurs formes :
| Type | Extensions typiques | Ce qu'ils contiennent |
|---|---|---|
| Dumps de base de données | .sql, .sql.gz, .dump |
données clients, commandes, hachages de mots de passe, paramètres |
| Archives du site | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
tout le code, configuration, uploads |
| Copies de fichiers individuels | .bak, .old, .orig, .save, .php~, .copy |
souvent des fichiers de configuration avec identifiants |
| Restes d'éditeurs | .swp, .swo, ~ en fin de nom |
parties de fichiers en cours d'édition |
| Sauvegardes d'extensions | sous-dossiers propres au CMS | sauvegardes complètes, parfois avec des noms devinables |
Les copies de fichiers de configuration sont particulièrement délicates. Le fichier d'origine config.php, le serveur l'exécute et son contenu reste caché. La copie config.php.bak, il la diffuse comme du texte, avec le mot de passe de la base de données.
Trouver les sauvegardes dans le webroot : recherche sur le serveur
La recherche suivante liste les fichiers suspects sous les webroots avec leur date et leur taille. Adaptez les chemins à votre serveur :
find /var/www /srv/www -type f \( \
-iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
-iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
-iname '*.rar' -o -iname '*.7z' -o \
-iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
-iname '*~' -o -iname '*.swp' \) \
-printf '%TY-%Tm-%Td %10s %p\n' 2>/dev/null | sort
Toutes les occurrences ne posent pas problème. Certaines archives sont mises à disposition volontairement en téléchargement, par exemple des manuels. Chaque fichier mérite toutefois une décision consciente. Soyez particulièrement attentif aux gros fichiers et aux dossiers des extensions de sauvegarde. Avec un hébergement mutualisé sans accès shell, l'aperçu des fichiers dans le panneau d'hébergement ou une consultation par SFTP aide.
Si vous trouvez dans le webroot un dump de base de données contenant des données clients, déplacez-le immédiatement hors du répertoire public et sauvegardez les journaux d'accès avant qu'ils ne soient archivés par rotation. Ce n'est qu'ensuite que vous déterminerez si le fichier a été appelé.
Le fichier a-t-il déjà été téléchargé ?
La réponse se trouve dans les journaux d'accès du serveur web. On cherche les appels réussis, c'est-à-dire de statut 200, sur les fichiers trouvés :
# Appels réussis aux extensions de sauvegarde typiques (format de journal Combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
| awk '$9 == 200 {print $4, $1, $7, $10}'
La sortie indique l'heure, l'adresse, le chemin et la taille de la réponse. Si la taille transférée correspond à la taille du fichier, le fichier a été chargé intégralement. La durée sur laquelle remontent les journaux dépend de la rotation. S'ils ne remontent pas jusqu'à la date de création du fichier, un appel antérieur ne peut être exclu. Cela est décrit en détail dans Analyser les journaux du serveur web après une attaque. Sans accès aux journaux bruts, par exemple en hébergement mutualisé, demandez à l'hébergeur les journaux de la période concernée.
Si un dump contenant des données personnelles a été appelé, ou si cela ne peut être exclu, l'examen d'une obligation de notification commence. Les bases sont résumées dans Obligation de notification RGPD : 72 heures après l'incident ; l'évaluation au cas par cas revient à votre délégué à la protection des données. Vous remplacez dans tous les cas les identifiants provenant de fichiers appelés.
Extensions de sauvegarde, panneaux et déménagements
De nombreuses découvertes remontent aux extensions de sauvegarde des CMS et des boutiques. Elles déposent souvent les sauvegardes dans un sous-dossier du webroot, parfois avec des noms composés de la date et du domaine, qui peuvent être devinés. Vérifiez trois réglages dans chaque extension : où sauvegarde-t-on ? Les copies locales sont-elles supprimées après le téléversement vers une destination externe ? Le dossier local est-il protégé contre un appel direct ?
Les sauvegardes issues des panneaux d'hébergement se trouvent en règle générale en dehors du webroot, par exemple dans le répertoire personnel. Cela devient problématique lorsque quelqu'un copie une telle sauvegarde dans le webroot parce que le téléchargement dans le navigateur est plus commode que par SFTP. Pour les déménagements, la règle est donc : transfert par SFTP ou directement entre les serveurs, jamais via un lien public.
Si des agences ou des prestataires gèrent vos sites, cette règle devrait aussi figurer dans le contrat, avec l'obligation de nettoyer après les travaux de maintenance. Des indications sont données dans Contrats avec les prestataires informatiques : définir clairement les obligations de sécurité.
Prévenir durablement : lieu de stockage et blocages
Pour que le problème ne se reproduise pas, deux niveaux sont nécessaires. Le premier est organisationnel : les sauvegardes ont un emplacement fixe en dehors du webroot et, en plus, en dehors du serveur. À quoi ressemble une sauvegarde fiable est décrit dans le guide Sauvegardes selon la règle 3-2-1.
Le second niveau est technique : le serveur web refuse par principe les extensions de sauvegarde typiques, même si un fichier reste malgré tout en place.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Vous ne bloquez des archives comme .zip que si votre site ne propose pas de téléchargements dans ce format, ou de façon ciblée dans les répertoires où aucun téléchargement ne se trouve. Une recherche automatique régulière avec notification et une courte règle d'équipe aident en complément : aucune sauvegarde ni copie dans le webroot, pas même pour cinq minutes. Des cas voisins, comme les fichiers de configuration cachés, sont traités dans Bien protéger les identifiants et les fichiers .env.
Comment PHP SOS aide-t-il concrètement ?
- Nous parcourons vos webroots à la recherche de dumps, d'archives, de copies et de sauvegardes d'extensions, et évaluons chaque découverte.
- Nous vérifions à l'aide des journaux d'accès si des fichiers ont été appelés, et documentons le résultat pour votre évaluation en matière de protection des données.
- Nous mettons en place des blocages dans le serveur web et une recherche automatique régulière.
- Nous déplaçons les sauvegardes vers un emplacement protégé en dehors du webroot.
Ces travaux font partie de notre durcissement de serveur pour serveurs web PHP.
Questions fréquentes
Pourquoi des sauvegardes se retrouvent-elles dans le webroot ?
Le plus souvent par commodité : un dump est généré pour un déménagement, une extension dépose des sauvegardes dans son propre dossier, ou l'on crée à la hâte, avant une modification, une copie d'un fichier avec l'extension .bak. Ensuite, le fichier tombe dans l'oubli.
Un fichier comme config.php.bak est-il dangereux ?
Très. Un fichier avec l'extension .php est exécuté par le serveur, son contenu reste caché. Une copie avec une autre extension est en revanche généralement diffusée comme du texte par le serveur, avec le mot de passe de la base de données et les clés.
Un dump de base de données accessible publiquement est-il une violation de données ?
S'il contient des données personnelles et a été appelé, ou si un appel ne peut être exclu, une obligation de notification au titre du RGPD entre en considération. L'évaluation au cas par cas relève de votre délégué à la protection des données ou de votre conseil juridique.
Où les sauvegardes devraient-elles se trouver à la place ?
En dehors du webroot et, en plus, en dehors du serveur, selon la règle 3-2-1. Au moins une copie devrait être stockée de façon que le serveur web lui-même ne puisse ni la supprimer ni la modifier.