SSRF : comprendre les risques et se protéger

Auteur : Rédaction Domeny.ForSale Publié le 20.10.2026

En bref : SSRF (Server-Side Request Forgery) est une vulnérabilité qui permet à un attaquant d’amener le serveur d’une application à envoyer une requête vers une adresse non prévue. Le serveur peut ainsi atteindre des ressources qui ne sont pas directement accessibles depuis Internet, par exemple des services du réseau interne. Contrairement à CSRF, qui exploite le navigateur de l’utilisateur, une attaque SSRF fait exécuter la requête par le serveur lui-même.

Comment fonctionne SSRF : un exemple simple

Imaginez une application qui permet d’ajouter une photo de produit en collant l’adresse d’une image. L’utilisateur fournit une URL, c’est-à-dire l’adresse d’une ressource, puis le serveur télécharge le fichier et l’enregistre dans le catalogue de la boutique. Cette fonction est pratique, mais l’application doit vérifier à quelle destination elle se connecte réellement.

Si elle accepte n’importe quelle adresse, un attaquant peut indiquer, à la place d’une image, un service accessible uniquement depuis le réseau du serveur. L’application devient alors un intermédiaire : elle envoie une requête vers une destination que l’attaquant ne pourrait pas atteindre lui-même. Si elle renvoie également le contenu reçu à l’utilisateur, elle risque de divulguer des données internes.

On peut comparer cela à un réceptionniste qui, à la demande de n’importe qui, va chercher des documents dans des pièces fermées. Le problème n’est pas de rapporter des documents, mais de ne pas vérifier où il est autorisé à les prendre et à qui il peut les remettre.

Récupérer des données à une adresse fournie par l’utilisateur ne constitue pas, en soi, une vulnérabilité. Une vulnérabilité SSRF apparaît lorsque l’utilisateur peut diriger une requête hors du périmètre autorisé et que l’application ne fait pas respecter les restrictions nécessaires.

Où rencontre-t-on SSRF et quelles peuvent en être les conséquences ?

SSRF peut toucher toute fonction qui se connecte à une autre ressource à partir de données contrôlées par l’utilisateur. Les cas typiques comprennent la génération d’aperçus de liens, l’importation de documents, le téléchargement d’images et la création de fichiers PDF à partir de pages web. Les webhooks, ces notifications automatiques envoyées à une adresse indiquée, présentent un risque similaire.

Les conséquences dépendent des ressources auxquelles le serveur a accès et de la manière dont l’application traite la réponse. Elles peuvent notamment être les suivantes :

lecture d’informations provenant de services internes ;
identification des services accessibles sur le réseau du serveur ;
accès aux métadonnées de l’environnement cloud, qui contiennent parfois des informations d’authentification ;
exécution d’une opération dans un service qui fait indûment confiance au trafic provenant du réseau interne.

Une vulnérabilité SSRF ne signifie pas automatiquement une prise de contrôle de l’ensemble du serveur. Le danger augmente toutefois lorsque l’application dispose d’un accès étendu au réseau et que les services internes n’exigent pas d’authentification.

Il existe aussi une variante appelée blind SSRF, ou SSRF à l’aveugle, dans laquelle l’attaquant ne voit pas directement la réponse de la ressource sollicitée. L’absence de contenu affiché ne supprime pas la vulnérabilité : le simple envoi d’une requête peut déclencher une opération indésirable ou révéler des informations à travers le comportement de l’application.

SSRF et CSRF : des noms proches, des mécanismes différents

CSRF (Cross-Site Request Forgery) consiste à amener le navigateur d’un utilisateur à envoyer une requête non souhaitée à une application. Le navigateur peut alors joindre automatiquement des données de session, par exemple le cookie d’un utilisateur connecté. L’objectif est généralement d’exécuter une opération avec les droits de cet utilisateur.

Dans le cas de SSRF, c’est le serveur qui exécute la requête, et l’attaque exploite son accès au réseau ainsi que ses éventuels droits. Elle ne nécessite pas, par définition, qu’une victime soit connectée, même si la fonction vulnérable peut elle-même n’être accessible qu’après connexion.

Caractéristique	SSRF	CSRF
Qui envoie la requête ?	Le serveur de l’application	Le navigateur de l’utilisateur
Qu’exploite l’attaque ?	L’accès et les droits du serveur	La session de l’utilisateur
Principe de protection	Contrôler les destinations des connexions et l’accès au réseau	Vérifier les requêtes qui modifient l’état de l’application, notamment au moyen de jetons CSRF

Ces protections ne sont pas interchangeables. Un jeton CSRF ne résout pas le problème d’un serveur qui récupère des données à des adresses interdites. À l’inverse, le filtrage des connexions sortantes ne remplace pas la protection de la session utilisateur.

Comment réduire le risque de SSRF

Commencez par déterminer si l’application doit réellement pouvoir récupérer des données à n’importe quelle adresse. Si l’intégration ne concerne qu’un seul service, il est plus sûr de conserver son adresse dans la configuration et de ne demander à l’utilisateur que l’identifiant de la ressource.

Lorsque la saisie d’adresses est nécessaire, mettez en place plusieurs couches de protection :

Limitez les destinations autorisées. Si la fonction le permet, utilisez une liste fermée d’hôtes, de ports et de protocoles de confiance. Ne vérifiez pas les adresses uniquement en y recherchant un fragment de texte.
Vérifiez les adresses IP de destination. Prenez en compte IPv4 et IPv6 et bloquez les plages non autorisées, notamment les réseaux privés, les adresses locales et les points d’accès spécifiques aux métadonnées cloud.
Contrôlez les redirections et le DNS. Une adresse apparemment sûre peut rediriger vers une ressource interdite. La vérification doit porter sur la destination réelle de la connexion, et pas seulement sur l’URL initiale.
Limitez le trafic sortant. Les règles réseau doivent empêcher l’application d’accéder aux services dont elle n’a pas besoin. Définissez également des délais d’attente et une taille maximale pour les réponses.

Ne transmettez pas automatiquement de cookies, de jetons ou d’autres informations d’authentification aux adresses indiquées par l’utilisateur. Dans un environnement cloud, consultez également la documentation officielle du fournisseur sur la protection du service de métadonnées.

Par où commencer la vérification de l’application ?

Dressez la liste des fonctions dans lesquelles le serveur récupère des données à partir d’une adresse ou d’une autre valeur fournie par l’utilisateur. Pour chacune, déterminez les destinations de connexion autorisées, la manière dont les redirections sont traitées et les données renvoyées à l’utilisateur.

Effectuez les tests uniquement dans votre propre environnement ou avec l’autorisation du propriétaire. Pour commencer, choisissez une fonction, par exemple l’importation d’une image, et vérifiez que ses restrictions s’appliquent aussi après une redirection, et pas seulement à l’adresse saisie dans le formulaire.

À lire aussi : Que signifie www ?