Tous les guides
Sévérité MoyenneGestion des fichiers, chemins et ressources

Index de répertoires ouverts : quand votre serveur de fichiers liste tout

Lorsque l'indexation des répertoires est activée, visiter un chemin comme /uploads/ renvoie une liste navigable de tous les fichiers de ce répertoire au lieu d'un 403 ou d'un 404. Les attaquants regardent là en premier, car des archives de sauvegarde, des fichiers de logs et des contenus uploadés par les utilisateurs restent régulièrement lisibles par tous dans des répertoires servis par le web.

Ce que c’est

Le listing de répertoires (ou indexation de répertoires) est une fonctionnalité du serveur web qui génère un navigateur de fichiers HTML lorsqu'un répertoire est demandé et qu'aucun fichier index n'est présent. Activé par défaut dans certaines configurations nginx (autoindex on) et dans Apache (Options +Indexes), c'est une commodité pour les hébergeurs statiques qui devient un risque partout où les fichiers ne devraient pas être publics.

AppSafe vérifie un ensemble de chemins souvent mal configurés — /uploads/, /files/, /backup/, /backups/, /logs/ et /tmp/ — et signale tout chemin qui renvoie un listing de répertoire reconnaissable. Un seul répertoire ouvert peut suffire à exposer des données qui n'auraient jamais dû être découvrables.

Pourquoi ça compte

Les répertoires exposés contiennent régulièrement des fichiers uploadés par les utilisateurs, des dumps de base de données compressés, des logs applicatifs contenant des identifiants ou des tokens de session, et des archives de code source laissées par des déploiements. Les trouver ne demande ni authentification ni exploitation — il suffit de taper l'URL.

Les scanners automatisés sondent en continu les mêmes chemins connus qu'AppSafe, sur chaque hôte joignable. Un répertoire /backup/ ouvert contenant un dump .sql.gz équivaut à un export complet de la base de données remis sans mot de passe.

Comment corriger

Désactiver autoindex dans nginx

Supprimez ou désactivez explicitement la directive autoindex dans tout bloc server ou location qui sert des répertoires contrôlés par les utilisateurs.

location /uploads/ {
  autoindex off;
  # Serve individual files but never list directory contents
}
Déplacer les répertoires sensibles hors de la racine web

La solution la plus sûre consiste à stocker uploads, sauvegardes et logs dans un répertoire que le serveur web ne sert pas du tout. Votre application lit et diffuse les fichiers via une route authentifiée — le chemin brut du système de fichiers n'est jamais accessible.

Dans Next.js, protéger l'accès aux fichiers par un route handler

Ne placez jamais les uploads des utilisateurs ou les sauvegardes dans le répertoire public/. Servez-les via une route API capable d'imposer l'authentification et d'assainir le chemin demandé.

// app/api/uploads/[filename]/route.ts
import { getSession } from "@/lib/auth-session";
import { readFile } from "fs/promises";
import path from "path";

export async function GET(
  _req: Request,
  { params }: { params: { filename: string } }
) {
  const session = await getSession();
  if (!session) return new Response(null, { status: 401 });

  // path.basename prevents directory traversal
  const safe = path.basename(params.filename);
  const filePath = path.join(process.cwd(), "private-uploads", safe);
  const data = await readFile(filePath);
  return new Response(data);
}
Protéger les endpoints de listing internes par authentification

Si vous avez réellement besoin d'une interface de fichiers navigable (une médiathèque, un visualiseur de logs interne), protégez le chemin par une authentification plutôt que de compter sur le fait que personne ne le trouvera.

location /logs/ {
  autoindex on;
  auth_basic "Internal only";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

FAQ

Le listing de répertoires est-il toujours un problème, ou seulement sur certains chemins ?

C'est un problème partout où les fichiers contiennent quoi que ce soit de sensible. Un CDN public qui sert des images statiques avec l'indexation activée est généralement inoffensif ; /logs/, /backup/ et /uploads/ ne le sont presque jamais, car ils accumulent des fichiers qui n'ont jamais été vérifiés pour un accès public.

Puis-je simplement déposer un index.html vide dans le répertoire pour bloquer le listing ?

Cela masque le listing de ce seul répertoire, mais laisse chaque sous-répertoire ouvert. C'est aussi facile à oublier lors de la création de nouveaux répertoires. Désactiver autoindex au niveau du serveur est une correction fiable, au niveau de la configuration, qui couvre tout ce qui se trouve en dessous.

Quelle sévérité AppSafe signale-t-il pour un index de répertoire ouvert ?

Moyenne. Le listing en lui-même n'est pas la compromission — c'est le chemin qui y mène. Un répertoire /backup/ navigable contenant un dump de base de données ou un répertoire /logs/ avec des tokens d'authentification en clair dépasse vite, à lui seul, le niveau moyen.

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 gratuitement