Path Traversal est une vulnérabilité présente depuis des décennies dans les manuels de sécurité, mais qui continue d’apparaître dans les applications modernes. L’Institut National de Cybersécurité espagnol (INCIBE) a consacré une nouvelle étude à cette faille, classée CWE-22, et avertit que le problème ne doit plus être associé uniquement aux applications web traditionnelles : microservices, conteneurs, API, plateformes cloud et systèmes d’intelligence artificielle peuvent être exposés dès qu’ils traitent des chemins contrôlables depuis l’extérieur.

Le Path Traversal en cinq points :

• Le Path Traversal permet de sortir du répertoire autorisé en manipulant les chemins traités par une application.
• Le risque concerne les configurations, identifiants, clés API, journaux et autres fichiers accessibles au processus vulnérable.
• INCIBE situe aussi ce problème dans les microservices, conteneurs, cloud, API REST et applications d’IA.
• Les techniques SAST, DAST et les tests de pénétration aident à détecter ces vulnérabilités avant leur déploiement en production.
• Canonicaliser les chemins, utiliser des allowlists et appliquer le principe du moindre privilège restent les principales mesures de défense.

L’origine du problème tient à une erreur bien connue de tout développeur : recevoir un paramètre, l’utiliser pour construire un chemin, puis y accéder sans vérifier correctement la destination finale. Une fonctionnalité en apparence anodine, comme le téléchargement de documents, le chargement d’images, l’importation de fichiers ou la sélection de modèles, peut ainsi devenir un point d’entrée malveillant. L’étude d’INCIBE-CERT rappelle que le Path Traversal figure dans la classification CWE de MITRE et reste lié aux problèmes de contrôle d’accès référencés par OWASP. Sa persistance prouve que moderniser une architecture ne suffit pas à effacer les erreurs fondamentales de programmation.

De ../ à l’accès à des fichiers hors du répertoire autorisé

L’exemple classique reste utile pour comprendre la faille. Supposons qu’une application stocke des documents dans /var/www/html/documents/ et reçoive via HTTP le nom du fichier à livrer : si le programme concatène directement ces deux chaînes, l’utilisateur contrôle une partie du chemin que le système d’exploitation résoudra ensuite. Sous Unix et Linux, ../ désigne le répertoire supérieur, et plusieurs séquences consécutives peuvent faire sortir un chemin relatif du répertoire prévu. INCIBE nomme cette modalité Path Traversal relatif (CWE-23), à laquelle s’ajoute le Path Traversal absolu (CWE-36), où une route complète est directement introduite.

L’exemple de /etc/passwd est souvent utilisé parce qu’il illustre facilement le problème sous Linux : si le processus du serveur dispose de droits de lecture et que l’application ne contrôle pas correctement le chemin, une requête manipulée peut conduire le programme à lire ce fichier au lieu du document prévu. Cela ne signifie pas pour autant que le Path Traversal donne directement un accès root ou une exécution à distance : son impact dépend des permissions du processus et des opérations possibles, et le risque augmente surtout quand les fichiers exposés contiennent des informations exploitables pour poursuivre l’attaque. Un fichier .env peut contenir des secrets de l’application, un fichier de configuration des identifiants de base de données, et les journaux peuvent révéler des informations internes sur les utilisateurs, chemins, services ou paramètres de fonctionnement.

INCIBE envisage aussi des scénarios plus avancés, comme l’accès à des informations sensibles, la montée en privilèges, voire l’exécution de code à distance (RCE) quand Path Traversal se combine avec d’autres vulnérabilités. La distinction est essentielle : le Path Traversal est le mécanisme qui permet de contourner la barrière du système de fichiers, l’impact final dépend de ce qui se trouve de l’autre côté et des permissions du processus.

Cloud, conteneurs et IA n’éliminent pas le problème

La partie la plus récente du rapport apparaît quand INCIBE sort du contexte d’une application web classique. L’organisme pointe explicitement microservices, conteneurs, plateformes cloud, API REST et solutions d’intelligence artificielle comme des environnements où la gestion correcte des chemins reste tout aussi cruciale, tout simplement parce que ces applications continuent d’utiliser des systèmes de fichiers malgré l’évolution de l’architecture.

Un service d’apprentissage automatique peut avoir besoin de localiser des modèles ou des jeux de données. Une plateforme IA gère souvent des points de contrôle (checkpoints), des fichiers temporaires ou des répertoires d’artefacts. Une API peut récupérer des documents stockés localement, et un microservice traiter des fichiers téléchargés par une autre composante. Dès qu’une entrée externe influence directement ou indirectement ces chemins, la surface d’attaque doit être contrôlée. Les conteneurs ajoutent une couche d’isolation supplémentaire, mais ne rendent pas pour autant une application vulnérable automatiquement sûre : si un processus compromis peut accéder à certains secrets, volumes montés ou configurations de son environnement, le Path Traversal permet d’y accéder tout autant.

C’est pourquoi INCIBE recommande de limiter le système de fichiers aux ressources strictement nécessaires, d’appliquer le principe du moindre privilège et d’isoler correctement les composants dans les architectures distribuées ou conteneurisées. C’est un principe important dans les architectures cloud native : la mitigation ne devrait pas reposer uniquement sur le code qui traite le chemin, les conséquences peuvent aussi être limitées en réduisant les données que le processus peut lire ou modifier.

Canonicaliser d’abord, valider ensuite

Une erreur courante consiste à transformer la protection en une course pour détecter des chaînes suspectes. Bloquer ../ semble suffisant jusqu’à ce que différents encodages, séparateurs, normalisations ou comportements propres au framework et au système d’exploitation viennent compliquer la tâche. L’étude évoque, dans le cadre des tests de sécurité, l’utilisation d’encodages URL ou Unicode pour vérifier si ces filtres peuvent être contournés, ainsi que des caractères spéciaux et des techniques historiques de troncature contre des contrôles faibles.

Une stratégie plus robuste consiste à déterminer d’abord la vraie ressource qui peut être demandée et à canonicaliser le chemin final que le système utilisera. INCIBE recommande d’utiliser systématiquement des allowlists lorsque c’est possible : si une application doit fournir un ensemble précis de documents, il est généralement plus sûr de travailler avec des identifiants ou des noms préautorisés que d’accepter n’importe quelle chaîne envoyée par le client. Les listes de refus tentent de reconnaître tout ce qui pourrait être dangereux, alors que les listes blanches inversent la logique en n’autorisant que les entrées connues et sûres à l’avance.

Quand le contexte exige plus de flexibilité dans la gestion des chemins, la canonicalisation devient essentielle : l’objectif est de convertir le chemin demandé en sa version définitive avant d’autoriser l’accès, puis de vérifier qu’il reste à l’intérieur du répertoire autorisé. Une chaîne qui semble partir de /var/www/html/documents/ mais se résout finalement vers une localisation externe doit être rejetée avant que le fichier ne s’ouvre. INCIBE illustre cela avec la fonction realpath() en PHP, mais le principe s’applique tout autant à d’autres langages et frameworks.

SAST et DAST, deux facettes d’une même vulnérabilité

L’étude aborde aussi Path Traversal du point de vue du cycle de développement logiciel. L’analyse statique de sécurité des applications (SAST) permet d’examiner le code sans l’exécuter, pour repérer les flux où des données utilisateur peuvent finir par atteindre des opérations sur des fichiers, notamment la concaténation directe de chemins ou l’appel à des fonctions d’ouverture ou de lecture avec des arguments dépendant d’entrées externes. L’analyse dynamique (DAST) offre une autre perspective : l’application tourne réellement, et les tests manipulent des paramètres d’URL, des formulaires ou d’autres entrées pour observer comment le serveur y répond.

INCIBE recommande aussi les tests de pénétration comme troisième approche, pour évaluer la vulnérabilité dans un contexte plus proche d’une attaque réelle. Les trois méthodes se complètent : le SAST identifie du code à risque avant déploiement, le DAST observe le comportement en fonctionnement, et le pentest étudie l’interaction avec les permissions, configurations et autres vulnérabilités. L’étude s’appuie aussi sur des laboratoires de la PortSwigger Web Security Academy et sur Burp Suite pour illustrer, en environnement contrôlé, des cas de détection et d’exploitation, comme une fonction de chargement d’images qui finit par retourner un fichier situé hors de la localisation prévue.

Zip Slip : le Path Traversal caché dans les archives

Le problème n’exige pas forcément un paramètre visible dans une URL. INCIBE évoque Zip Slip, une variante qui apparaît lors de l’extraction de fichiers ZIP, TAR, JAR et autres formats compressés : chaque fichier d’une archive peut porter une information sur son chemin d’extraction, et si une application s’y fie sans la vérifier, une entrée malveillante peut tenter d’écrire en dehors du répertoire de destination. Selon les permissions disponibles, cela peut affecter des configurations, bibliothèques, exécutables ou d’autres ressources.

Malgré la différence de vecteur, INCIBE y retrouve la même erreur de fond : ne pas valider correctement une route avant de l’utiliser pour accéder au système de fichiers. La mitigation consiste à résoudre et canoniser la destination, vérifier qu’elle reste dans le répertoire autorisé, et exécuter avec le moindre privilège possible. Ce vecteur est particulièrement critique dans les services modernes qui reçoivent des paquets, datasets, plugins, modèles, sauvegardes ou artefacts produits par d’autres systèmes, un peu à l’image des angles morts que soulève aussi Gartner sur l’IA qui traque les failles à grande échelle.

La dernière ligne de défense : permissions et surveillance

Un développement sécurisé devrait éviter que la traversée de répertoires ait lieu, mais limiter les privilèges réduit l’impact potentiel en cas d’échec. INCIBE recommande de configurer le serveur web pour restreindre l’accès à certains répertoires, de désactiver les fonctionnalités non nécessaires et de limiter l’accès du processus aux seules ressources indispensables. Il est aussi conseillé de journaliser et de surveiller les accès aux fichiers : un SIEM (Security Information and Event Management) peut aider à repérer des comportements anormaux ou des tentatives répétées d’accès à des chemins inattendus, une approche qui rejoint la logique de détection décrite dans la faille réseau révélée par NatJack sur le NAT de Windows, Linux et macOS.

Path Traversal illustre ainsi un problème fréquent en sécurité logicielle : dans une architecture moderne, des vulnérabilités très anciennes peuvent persister dès que des données externes sont traitées comme des instructions implicites pour accéder au système. Cloud, Kubernetes, conteneurs ou IA changent l’emplacement et le contenu des fichiers, mais la règle de fond reste la même : une application ne devrait jamais faire confiance à un chemin simplement parce qu’il provient d’une API en apparence légitime.

Questions fréquentes

Quelle différence entre Path Traversal relatif et absolu ?

Le Path Traversal relatif utilise des références à des répertoires supérieurs pour tenter d’échapper à la localisation prévue. Le Path Traversal absolu tente de fournir directement un chemin complet vers une ressource du système. INCIBE les associe respectivement à CWE-23 et CWE-36.

Un Path Traversal peut-il exister dans un conteneur ?

Oui. L’isolation peut limiter l’impact, mais une application vulnérable peut toujours accéder aux fichiers disponibles pour son processus dans le conteneur ou dans les ressources montées. INCIBE recommande une validation rigoureuse des chemins, l’isolation et le principe du moindre privilège.

Bloquer la chaîne ../ suffit-il ?

Non. Les chemins peuvent être encodés ou représentés de différentes manières, ce qui rend ce filtre insuffisant à lui seul. Mieux vaut utiliser des allowlists, canonicaliser le chemin et vérifier qu’il reste dans le répertoire autorisé.

Quels outils permettent de détecter le Path Traversal ?

INCIBE recommande des analyses SAST, DAST et des tests de pénétration. En pratique, des outils comme Burp Suite et les laboratoires de la PortSwigger Web Security Academy servent à analyser requêtes et réponses dans un environnement contrôlé, pour repérer facilement ces vulnérabilités.