Sauvegardes de base de données exposées : que se passe-t-il quand /backup.sql est accessible
Les sauvegardes de base de données — fichiers .sql, dumps compressés, archives zip de la base — sont parfois créées directement dans un répertoire accessible depuis le web et y restent. Une seule requête réussie vers /backup.sql ou /dump.sql livre à un attaquant chaque ligne de chaque table, sans jamais toucher à la logique de votre application.
Ce que c’est
Les scripts de sauvegarde, les panneaux de contrôle d'hébergement et les outils d'export manuel écrivent souvent des dumps avec des noms prévisibles : backup.sql, dump.sql, database.sql, db.sql.gz, backup.zip. Quand ils atterrissent dans la racine web et que le serveur ne les bloque pas explicitement, ils deviennent de simples fichiers téléchargeables. Les attaquants lancent des scans automatisés qui demandent des dizaines de ces noms courants à chaque hôte joignable.
AppSafe vérifie les chemins les plus courants — /backup.sql, /dump.sql, /database.sql, /db.sql.gz et d'autres — et signale tout chemin qui renvoie une réponse 200 avec un contenu ressemblant à un dump SQL ou à une archive. La vérification détecte aussi bien le SQL en texte brut que les formats compressés.
Pourquoi ça compte
Un dump SQL contient chaque ligne de chaque table au moment de sa création : comptes utilisateurs, hashs de mots de passe, adresses e-mail, données personnelles, tokens de session, historique de paiement et état interne de l'application. Télécharger un dump ne demande qu'une seule requête HTTP, qui ne laisse aucune trace dans les logs de votre application — le serveur web le sert comme n'importe quel fichier statique.
Contrairement à une clé API divulguée, une base de données divulguée ne se fait pas tourner. Une fois que quelqu'un possède une copie de votre table users, la fuite est définitive pour ces utilisateurs. Selon le contenu du dump, vous pouvez être tenu de notifier la violation au titre du RGPD, du CCPA ou de la HIPAA, avec le coût opérationnel de prévenir chaque utilisateur concerné.
Comment corriger
La bonne solution consiste à écrire les sauvegardes dans un répertoire que le serveur web ne peut pas atteindre — un chemin comme /var/backups/ ou un bucket de stockage objet avec des ACL privées, et non un sous-répertoire de /var/www/. Passez en revue les tâches cron et scripts de sauvegarde et mettez à jour le chemin cible.
En défense en profondeur, refusez au niveau du serveur les requêtes vers les fichiers SQL et les extensions d'archive courantes, quel que soit l'emplacement des fichiers.
location ~* \.(sql|sql\.gz|bak|dump|tar|tar\.gz|tar\.bz2|zip)$ {
deny all;
return 404;
}Si vous trouvez un fichier exposé, supprimez-le immédiatement. Puis déterminez comment il est arrivé là — corrigez le script ou le processus qui l'a déposé, pour qu'il ne réapparaisse pas à la prochaine exécution planifiée.
Après le nettoyage, confirmez que les chemins courants sont bien bloqués.
for path in /backup.sql /dump.sql /database.sql /db.sql.gz; do
code=$(curl -so /dev/null -w "%{http_code}" "https://yourdomain.com$path")
echo "$path → $code"
done
# Every line must print 404FAQ
Comment un attaquant saurait-il qu'il faut essayer /backup.sql sur mon site ?
Il ne vous cible pas spécifiquement. Des scanners automatisés demandent en continu des dizaines de noms de sauvegarde courants à des millions d'hôtes. Un fichier qui existe renvoie 200 et est téléchargé avant même que vous pensiez à vérifier.
Le fichier n'est resté en ligne qu'une heure. Le mal est-il fait ?
Peut-être. Les scans automatisés tournent jour et nuit, et les fichiers sont souvent trouvés quelques minutes après leur apparition. Si vous avez des logs d'accès, vérifiez si le chemin a été demandé — si c'est le cas, traitez-le comme une violation avérée.
Puis-je simplement protéger le fichier par mot de passe au lieu de le déplacer ?
Une authentification basique sur un seul fichier est fragile et facile à mal configurer. La bonne réponse est de retirer complètement le fichier de tout emplacement accessible depuis le web. Les sauvegardes doivent se trouver là où le serveur HTTP ne peut pas aller.
Votre app est-elle concernée ?
AppSafe détecte ce problème et des dizaines d’autres en un seul scan gratuit.
Scanner mon app gratuitementGuides liés
Index de répertoires ouverts : quand votre serveur de fichiers liste tout
Un serveur de fichiers qui liste son contenu offre aux attaquants un inventaire gratuit.
Fichiers .env exposés : comment les attaquants trouvent vos secrets
Un seul .env accessible peut livrer toute votre stack.
Supabase Row Level Security (RLS) : verrouillez vos tables
Votre anon key est publique. Le RLS est la seule chose qui la sépare de vos données.
Répertoire .git exposé : la fuite de code source cachée à la vue de tous
Un /.git accessible livre l'intégralité de votre base de code et de l'historique des commits.