Le dossier wp-content/uploads/ sert un but précis : rendre des fichiers accessibles publiquement, par conception. Tout ce qui y est déposé devient, sauf configuration serveur contraire, consultable par n’importe quel visiteur connaissant ou devinant son chemin. Un audit d’infrastructure a retrouvé un export complet de base de données stocké précisément à cet endroit.
Le fichier, nommé backup-2023-06-01.sql, pesait 340 Mo et se trouvait dans un sous-dossier daté du dossier uploads, aux côtés des images du mois correspondant. Il contenait l’intégralité des tables du site : contenus, utilisateurs avec leurs mots de passe hachés, clés API stockées en option, commandes WooCommerce avec adresses complètes.
Ce qu’on observe
Le script de sauvegarde, écrit par un précédent prestataire, exécutait un mysqldump planifié via une tâche cron système, puis déposait directement le fichier résultant dans le dossier uploads du site, probablement parce que ce dossier disposait déjà des droits d’écriture nécessaires pour l’utilisateur système exécutant le script.
#!/bin/bash
DATE=$(date +%Y-%m-%d)
mysqldump -u wp_user -p"$DB_PASS" wordpress_db > /var/www/site/wp-content/uploads/2023/06/backup-$DATE.sql
Aucun mécanisme de purge automatique, aucune restriction d’accès au niveau du serveur web, aucune limitation du nom de fichier ne protégeait ce dépôt. Le fichier restait indéfiniment accessible à l’URL directe correspondante, exactement comme n’importe quelle image du même dossier.
Pourquoi c’est un problème
Le dossier uploads n’est protégé par aucune authentification par défaut, ce comportement étant précisément celui recherché pour les médias destinés à être affichés sur le site public. Y placer un fichier qui ne devrait jamais être public revient à contredire directement la fonction du dossier, sans qu’aucune erreur de configuration ne soit nécessaire pour que l’exposition se produise : le comportement par défaut suffit.
- Le fichier était référencé nulle part dans le site, mais restait consultable par accès direct à l’URL.
- Des robots d’indexation avaient déjà exploré une partie de l’arborescence datée du dossier.
- Aucune rotation ni suppression des anciens exports n’était en place, accumulant les fichiers mois après mois.
Quoi faire à la place
La correction ne consiste pas à renommer le fichier ou à le déplacer dans un sous-dossier moins visible : un chemin discret n’est jamais un contrôle d’accès, seulement un obstacle contournable par simple énumération ou indexation. La solution consiste à stocker les exports entièrement hors de toute racine servie par le serveur web.
#!/bin/bash
DATE=$(date +%Y-%m-%d)
DOSSIER_EXPORT=/var/backups/wordpress
mkdir -p "$DOSSIER_EXPORT"
mysqldump -u wp_user -p"$DB_PASS" wordpress_db > "$DOSSIER_EXPORT/backup-$DATE.sql"
# Purge des exports de plus de 30 jours.
find "$DOSSIER_EXPORT" -name "backup-*.sql" -mtime +30 -delete
Le dossier /var/backups/wordpress se situe hors de la racine web /var/www/site, ce qui rend tout accès via une URL structurellement impossible, indépendamment de toute règle de réécriture ou de permission de fichier ajoutée après coup.
Renforcer la défense en profondeur
Au-delà du déplacement du dossier, deux mesures complémentaires ont été ajoutées pour éviter qu’une régression future ne réintroduise le même risque : un blocage explicite au niveau du serveur web de toute extension .sql dans le dossier uploads, et une alerte automatisée en cas de détection d’un tel fichier.
| Mesure | Effet |
|---|---|
| Export hors racine web | Élimine l’accès direct par construction |
| Blocage des .sql dans uploads | Filet de sécurité en cas de script mal configuré |
| Purge automatique après 30 jours | Réduit la fenêtre d’exposition en cas d’oubli |
Repère retenu de cet audit : si un fichier ne doit être consulté par personne d’autre que l’administrateur système, sa place n’est jamais dans un dossier conçu pour être public, quel que soit le nom qu’on lui donne.
En résumé
Ce défaut ne provient d’aucune faille logicielle : il provient d’un choix d’emplacement de fichier, motivé par la simplicité d’écriture plutôt que par une réflexion sur la visibilité résultante. Le sujet de la stratégie de sauvegarde elle-même — fréquence, rétention, chiffrement — relève d’une réflexion distincte, traitée côté hébergement ; celui-ci porte uniquement sur l’emplacement où un export, quel qu’il soit, ne doit jamais résider.
