## [A10:2025 – Mishandling of Exceptional Conditions / SSRF](https://owasp.org/Top10/fr/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/)
Les failles SSRF surviennent lorsqu'une application Web récupère une ressource distante sans vérifier correctement l'URL fournie par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête vers une destination inattendue, même derrière un pare-feu, VPN ou ACL réseau.
La faille **SSRF (Server-Side Request Forgery)** se produit lorsqu'une application web récupère une ressource distante sans valider correctement l'URL fournie par l'utilisateur. Dans ce cas, un attaquant peut forcer l'application à envoyer une requête vers des destinations internes ou externes inattendues, même protégées par un pare-feu, un VPN ou des ACL réseau.
Les applications modernes (API, microservices) rendent la récupération d'URL courante. La sévérité de SSRF augmente avec l'usage de services cloud et la complexité des architectures.
Cette vulnérabilité est particulièrement critique dans les architectures modernes utilisant des API et des microservices, où les services communiquent fréquemment entre eux. Son impact augmente également dans les environnements cloud, car un SSRF peut permettre d'accéder à des métadonnées sensibles de l'infrastructure ou de pivoter vers d'autres services internes.
### Exemples concrets
* Une API Node.js qui télécharge un fichier depuis une URL fournie par l'utilisateur peut être exploitée pour accéder à `http://169.254.169.254/latest/meta-data/` dans AWS et récupérer des credentials temporaires.
* Un service Python Flask qui interroge d'autres microservices internes peut être manipulé pour exfiltrer des informations ou provoquer des actions non autorisées sur le réseau interne.
* Une fonction de conversion d'images qui récupère des fichiers externes sans filtrage peut être détournée pour scanner le réseau interne ou déclencher des requêtes vers des services non exposés.
### Comment s'en prémunir
* Valider strictement les données d'entrée.
* Autoriser uniquement des schémas, ports et destinations prédéfinis.
* Ne jamais renvoyer directement le contenu récupéré à l'utilisateur.
* Désactiver les redirections HTTP non nécessaires.
Pour sécuriser vos applications, il est essentiel d'adopter plusieurs pratiques :
* Valider strictement les données d'entrée. Ne jamais faire confiance à l'URL fournie par l'utilisateur.
* Autoriser uniquement des schémas (`http`, `https`), ports et destinations prédéfinis. Par exemple, limiter les requêtes aux domaines de confiance ou aux adresses IP spécifiques.
* Ne jamais renvoyer directement le contenu récupéré à l'utilisateur. Préférer un traitement côté serveur et un retour contrôlé des données nécessaires.
* Désactiver les redirections HTTP non nécessaires pour éviter qu'une requête légitime soit redirigée vers un service interne.
* Utiliser des bibliothèques sécurisées pour les requêtes HTTP (comme `axios` ou `requests`) et appliquer des filtres ou whitelists pour les URLs.
* Sur le cloud, limiter l'accès aux métadonnées et utiliser des rôles IAM avec le principe du moindre privilège.
On peut expérimenter des requêtes SSRF dans un environnement contrôlé, tester la validation d'URL et observer comment un filtrage strict empêche l'accès à des services internes ou sensibles.
