Attaque SSRF : le Server-Side Request Forgery expliqué

Qu'est-ce que le SSRF ?

Le Server-Side Request Forgery (SSRF) est une vulnérabilité web où un attaquant fait envoyer par un serveur des requêtes HTTP vers une destination qu'il contrôle. Au lieu que la machine de l'attaquant atteigne une cible, c'est le serveur vulnérable qui le fait, en utilisant sa propre position réseau, son adresse IP et ses relations de confiance.

Le danger vient de l'endroit où se trouve le serveur. Les serveurs d'application vivent généralement à l'intérieur d'un réseau, derrière le pare-feu, à côté des bases de données, des API internes, des panneaux d'administration et des services de métadonnées cloud. Ces systèmes font confiance au trafic du serveur d'application parce qu'il est "à l'intérieur". Le SSRF offre cette position interne à un tiers.

Le motif vulnérable est toute fonctionnalité qui prend une URL ou un nom d'hôte depuis une entrée utilisateur et le récupère : envoyeurs de webhooks, générateurs d'aperçu d'URL, moteurs de rendu PDF ou image qui chargent des ressources distantes, uploaders "importer depuis une URL", et dérouleurs de liens open-graph. Chacun est une requête que le serveur effectue en votre nom, et si vous contrôlez la cible, vous contrôlez où le serveur pointe sa propre connexion de confiance.

Où apparaît le SSRF

• Récupérateurs d'URL - champs "entrez une URL d'image" ou "importer depuis un lien" qui tirent du contenu distant côté serveur.
• Webhooks - les intégrations qui envoient un POST vers une URL de callback fournie par l'utilisateur sont du SSRF par conception si la destination n'est pas restreinte.
• Processeurs de documents et d'images - les convertisseurs HTML-vers-PDF qui suivent les sources <img> et <iframe> sont une surface classique de SSRF aveugle.
• Outils d'analyse et d'aperçu - les dérouleurs de liens qui récupèrent une page pour construire une carte d'aperçu récupèreront tout aussi volontiers des pages internes.

Comment fonctionne une attaque SSRF

Une attaque SSRF a trois pièces mobiles : une fonctionnalité qui récupère une URL, une entrée que vous contrôlez, et une destination que le développeur n'a jamais voulu que vous atteigniez. Le déroulé est court.

1. Trouvez la récupération. Localisez un paramètre qui fait requêter une URL par le serveur. Il peut être évident (?url=https://example.com/logo.png) ou caché dans du JSON, une config de webhook, ou un document XML.
2. Redirigez-la vers l'intérieur. Remplacez l'URL externe par une cible interne : http://localhost/admin, http://127.0.0.1:8080, ou une plage privée comme http://10.0.0.5.
3. Lisez la réponse, ou déduisez-la. Si le serveur vous renvoie le contenu récupéré, c'est du SSRF in-band et vous voyez le résultat directement. Sinon, vous vous rabattez sur les différences de timing et d'erreur pour confirmer que la requête a eu lieu. C'est le SSRF aveugle.

Prenez une fonctionnalité d'aperçu qui appelle GET /api/preview?url=https://site.com. Le serveur récupère l'URL que vous passez. Envoyez url=http://169.254.169.254/latest/meta-data/ et, sur une instance AWS non protégée, le serveur retourne ses propres métadonnées cloud. Voilà toute l'attaque : vous n'avez jamais touché le réseau interne, le serveur s'y est plongé et vous a remis le résultat.

En pratique, la première chose à tester est une URL que vous contrôlez, comme un endpoint de journalisation de requêtes. Si le serveur cible s'y connecte, vous avez prouvé que la récupération se fait côté serveur et que le SSRF est réel avant de perdre du temps sur des cibles internes. Cela vous indique aussi l'IP de sortie du serveur, un contexte utile pour la suite du test.

SSRF in-band vs SSRF aveugle

Le SSRF se divise en deux familles selon que vous pouvez voir la réponse ou non. La distinction décide de toute votre approche de test.

SSRF in-band

Le SSRF in-band retourne le contenu récupéré directement dans la réponse HTTP. Vous envoyez url=http://localhost/admin et la page d'administration revient dans la réponse. C'est le cas bruyant et facile : vous lisez les réponses internes aussi clairement que si vous y aviez navigué vous-même. Le vol de métadonnées cloud et l'accès aux panneaux d'administration internes passent généralement par du SSRF in-band.

SSRF aveugle

Le SSRF aveugle fait envoyer la requête par le serveur, mais la réponse ne vous revient jamais. Le serveur récupère votre URL et jette le corps, donc vous ne pouvez pas lire directement les pages internes. C'est tout de même dangereux. Vous le confirmez avec une interaction hors bande (pointez le serveur vers un domaine que vous surveillez et guettez la résolution DNS ou le hit HTTP), puis vous l'exploitez via des effets de bord : déclencher des actions internes, scanner des ports par timing, ou atteindre des services qui agissent sur une requête sans avoir besoin de retourner un corps.

Avis tranché : ne classez pas par habitude un SSRF aveugle comme de faible sévérité. Un SSRF aveugle contre un endpoint de métadonnées cloud qui accepte une requête et exécute une action, ou contre un service interne avec un handler GET dangereux, peut être tout aussi grave que la version in-band. L'absence de réponse visible limite votre confort, pas l'impact.

Payloads SSRF et exemples d'attaque

La valeur d'un SSRF dépend entièrement de ce que le serveur peut atteindre et que vous ne pouvez pas. Voici les cibles qui transforment un bug "récupère une URL" en un vrai incident.

Endpoints de métadonnées cloud

La cible SSRF de plus grande valeur sur un hôte cloud est le service de métadonnées d'instance. Sur AWS, Azure et Google Cloud, il réside à l'adresse link-local 169.254.169.254 et, sur les configurations plus anciennes, sert des identifiants temporaires à tout ce qui les demande depuis l'instance elle-même.

# AWS IMDSv1 - récupérer les identifiants du rôle de l'instance
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Google Cloud - exige un en-tête, qu'un SSRF dans un proxy peut ajouter
http://metadata.google.internal/computeMetadata/v1/

Sur une instance autorisant encore IMDSv1, ces identifiants permettent à un attaquant d'agir en tant que rôle cloud du serveur. Cette seule requête explique pourquoi le SSRF est traité comme une découverte de sévérité critique sur l'infrastructure cloud, et pourquoi AWS a imposé IMDSv2 (qui exige un jeton de session) par défaut.

Services internes et scan de ports

Pointez la récupération vers le loopback et les plages privées pour atteindre des services qui n'attendaient jamais de trafic externe :

# Interfaces d'administration internes
http://127.0.0.1:8080/admin
http://localhost/server-status

# Magasins de données internes non authentifiés
http://127.0.0.1:6379   # Redis
http://127.0.0.1:9200   # Elasticsearch

En variant le port et en mesurant le temps de réponse ou le type d'erreur, vous pouvez cartographier quels ports internes sont ouverts, en utilisant le serveur vulnérable comme un scanner qu'il n'a pas choisi d'être.

Contournements de filtres

La plupart des défenses SSRF sont des blocklists naïves qui cherchent les chaînes 127.0.0.1 ou localhost. Elles tombent devant de simples astuces d'encodage, ce qui est précisément pourquoi les blocklists sont la mauvaise approche :

http://127.1                      # forme courte de 127.0.0.1
http://2130706433                 # 127.0.0.1 en entier décimal
http://[::1]                      # loopback IPv6
http://0177.0.0.1                 # notation octale
http://localhost.attacker.com     # enregistrement DNS qui résout vers 127.0.0.1

Les schémas file://, gopher:// et dict:// élargissent encore l'attaque, laissant le SSRF lire des fichiers locaux ou forger des paquets bruts vers des services internes quand la bibliothèque de récupération le supporte.

SSRF vs CSRF : ce n'est pas la même chose

Le SSRF forge une requête depuis le serveur ; le CSRF forge une requête depuis le navigateur de la victime. Les noms se ressemblent et les acronymes trompent en entretien, mais les deux attaques ciblent des extrémités opposées de la connexion.

• SSRF (Server-Side Request Forgery) - l'attaquant abuse du serveur pour atteindre des systèmes internes. Le serveur est l'adjoint confus qui fait des requêtes pour le compte de l'attaquant.
• CSRF (Cross-Site Request Forgery) - l'attaquant abuse du navigateur d'un utilisateur connecté pour effectuer des actions sur un site où l'utilisateur est authentifié. Le navigateur de la victime est l'adjoint confus.

Le SSRF vous donne une portée dans un réseau ; le CSRF vous donne des actions sous la session d'un autre. Pour l'analyse complète du forgeage de requêtes côté client et de son cousin le cross-site scripting, voyez notre guide sur XSS vs CSRF.

Comment prévenir le SSRF

Comment prévenir le SSRF ? Imposez une allowlist stricte de destinations autorisées, bloquez les requêtes vers les plages IP internes et l'endpoint de métadonnées cloud, puis résolvez et validez le nom d'hôte avant que la requête ne soit faite. Le seul filtrage des entrées ne fonctionne pas, car l'encodage et les astuces DNS défont toute blocklist.

Superposez ces contrôles, puisqu'aucun seul ne suffit à lui-même :

• Allowlist, pas blocklist. N'autorisez que les domaines ou IP spécifiques dont la fonctionnalité a légitimement besoin. Tout le reste est refusé par défaut. C'est le seul contrôle qui tient vraiment.
• Bloquez les plages internes. Rejetez les requêtes vers 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, et la plage link-local 169.254.0.0/16 qui couvre les métadonnées cloud.
• Résolvez avant de récupérer. Résolvez le nom d'hôte en une IP, vérifiez cette IP contre vos règles, puis requêtez cette IP exacte. Cela ferme la faille du DNS rebinding où un nom passe la validation mais résout vers quelque chose d'interne au moment de la récupération.
• Imposez IMDSv2. Sur AWS, exigez des métadonnées d'instance basées sur un jeton de session pour qu'un simple GET SSRF ne puisse pas soulever d'identifiants. C'est une mitigation gratuite et à fort impact.
• Désactivez les schémas dangereux. N'autorisez que http et https. Rejetez file://, gopher://, dict:// et consorts d'emblée.

Lors de tests d'applications réelles, la mitigation qui échoue le plus souvent est l'étape "résolvez avant de récupérer". Les équipes ajoutent une allowlist et un blocage des plages privées, puis valident la chaîne du nom d'hôte mais récupèrent l'URL à neuf, laissant un enregistrement DNS basculer entre la vérification et la requête. Validez l'IP résolue, et récupérez cette IP, pas le nom.

Le SSRF dans l'OWASP Top 10

Le SSRF a une histoire inhabituelle dans l'OWASP Top 10. L'édition 2021 l'a promu à sa propre place dédiée, A10, en grande partie grâce à l'enquête communautaire qui l'a signalé comme une préoccupation montante pour les applications modernes connectées au cloud.

Dans la révision 2025, le SSRF a perdu son entrée autonome et est passé dans le Broken Access Control. C'était une reclassification, pas une rétrogradation : les données ont montré que le SSRF s'y intègre naturellement comme un échec de contrôle d'accès, puisqu'il s'agit fondamentalement du serveur qui fait une requête qu'il n'aurait pas dû être autorisé à faire. La fiche OWASP et l'entrée correspondante CWE-918 restent les définitions de référence.

Pour le tableau complet de la place du SSRF parmi les dix risques et de ce qui a changé entre les listes 2021 et 2025, notre guide OWASP Top 10 cartographie chaque catégorie avec un exemple travaillé. Le SSRF apparaît aussi constamment dans les tests d'API, où un paramètre de récupération côté serveur est une découverte fréquente, que vous pouvez travailler dans le lab API Breaker.

Considérations légales et éthiques

• Testez le SSRF uniquement sur des systèmes que vous possédez, dans des labs dédiés, ou dans le périmètre défini d'un engagement autorisé.
• Les identifiants de métadonnées cloud sont des secrets actifs. Si vous les récupérez lors d'un test autorisé, traitez-les comme des découvertes sensibles, ne les utilisez pas au-delà de la preuve d'impact, et signalez-les immédiatement.
• La confirmation d'un SSRF aveugle doit utiliser un endpoint collaborateur que vous contrôlez, jamais l'infrastructure d'un tiers.
• Entraînez-vous sur des cibles volontairement vulnérables, pas sur des applications aléatoires d'internet. Les labs ci-dessous existent exactement pour cela.