webSSRFcloud

Server-Side Request Forgery (SSRF) : la faille qui ouvre votre cloud

Name: CleanIssue
Price range: €€

Publié le 2026-04-037 min de lectureCleanIssue

> En bref : Comment la SSRF permet d'atteindre les services internes de votre infrastructure cloud, avec des scénarios réels AWS, GCP et Azure.

Qu'est-ce que la SSRF

La Server-Side Request Forgery force votre serveur à émettre des requêtes HTTP vers des destinations choisies par l'attaquant. Au lieu d'attaquer directement votre infrastructure interne, l'attaquant utilise votre application comme proxy. C'est particulièrement dangereux en environnement cloud où le serveur a accès à des services internes non exposés sur Internet.

Le scénario classique : métadonnées cloud

Tous les grands clouds exposent un service de métadonnées accessible uniquement depuis les instances. Sous AWS, c'est http://169.254.169.254/latest/meta-data/. Si votre application accepte une URL fournie par l'utilisateur et effectue une requête côté serveur (prévisualisation d'un lien, import d'image, webhook), l'attaquant peut demander cette adresse interne.

Impact réel : en 2019, Capital One a été compromise via une SSRF qui a permis de récupérer les identifiants IAM temporaires depuis les métadonnées EC2. Plus de 100 millions de dossiers clients ont été exposés.

Où se cachent les SSRF

Prévisualisation de liens : l'application récupère le titre et l'image d'une URL pour l'afficher (unfurling)

Import de fichiers par URL : téléchargement d'images ou de documents depuis une URL fournie

Webhooks sortants : l'utilisateur configure une URL de callback

Intégrations PDF : génération de PDF à partir d'HTML qui charge des ressources externes

Proxies d'API : l'application relaie des requêtes vers des services configurables

Les techniques de contournement

Les filtres basiques sont facilement contournés :

Encodage IP : 169.254.169.254 peut s'écrire 0xa9fea9fe, 2852039166 (décimal), ou 0251.0376.0251.0376 (octal)

DNS rebinding : un domaine qui résout d'abord vers une IP autorisée, puis vers l'IP interne lors de la deuxième résolution

Redirections : l'URL pointe vers un serveur contrôlé qui redirige (302) vers la cible interne

Fragments et authentification : http://evil.com@169.254.169.254 peut tromper certains parsers d'URL

Défenses efficaces

IMDSv2 sur AWS : ce mécanisme exige un header spécial pour accéder aux métadonnées. Il bloque la majorité des SSRF car l'attaquant ne peut pas ajouter de headers à la requête initiale.

Liste blanche de destinations : si votre fonctionnalité n'a besoin que de quelques domaines, n'autorisez que ceux-là. Rejetez tout le reste.

Résolution DNS puis validation : résolvez le domaine, vérifiez que l'IP n'est pas privée (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16), puis effectuez la requête vers l'IP validée avec le header Host original.

Réseau isolé : exécutez les fonctions de fetch dans un réseau qui n'a accès ni aux métadonnées ni aux services internes. Les architectures serverless facilitent cette isolation.

Pas de suivi de redirections : ou alors revalidez chaque étape de la chaîne de redirections.

GCP et Azure aussi

Sur GCP, le service de métadonnées est à http://metadata.google.internal/computeMetadata/v1/ et exige le header Metadata-Flavor: Google. Sur Azure, c'est http://169.254.169.254/metadata/instance avec le header Metadata: true. La protection par header rend l'exploitation plus difficile mais pas impossible si l'application permet de contrôler les headers de la requête sortante.

En audit

Chez CleanIssue, nous testons systématiquement les fonctionnalités de fetch externe contre les adresses de métadonnées cloud. La SSRF est souvent combinée avec d'autres failles pour obtenir un impact critique. Parlez-nous de votre revue externe pour évaluer votre exposition.

À retenir

Identifiez et testez vos surfaces d'attaque exposées avant qu'un tiers ne le fasse.

Les contrôles de sécurité côté client (frontend) ne remplacent jamais une validation côté serveur.

Un audit régulier est plus efficace qu'un audit ponctuel — les failles apparaissent à chaque déploiement.

Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.

Sécurité cloud AWS, GCP, Azure : les 10 erreurs IAM les plus courantes

Les erreurs de configuration IAM qui exposent votre infrastructure cloud : permissions excessives, credentials statiques, MFA manquant, et plus.

2026-04-08 · 8 min de lecture

CVENext.js

Next.js CVE-2026-44578 : une SSRF via WebSocket sur les instances auto-hébergées

Une faille SSRF (CVSS 8.6) dans le serveur Node.js intégré de Next.js permet à un attaquant non authentifié de faire proxifier des requêtes vers vos services internes. Vercel n'est pas touché, l'auto-hébergement oui. Correctif : 15.5.16 / 16.2.5.

2026-07-09 · 6 min de lecture

cloudKubernetes

Kubernetes : 7 vulnérabilités critiques que nous trouvons en audit

Les sept failles de configuration Kubernetes les plus fréquentes dans nos audits : RBAC, secrets, network policies, pods privilégiés et plus.

2026-04-09 · 7 min de lecture

Sources

Rédigé par CleanIssue

Revu le 2026-04-03

Services associés

Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.

Audit Complet

Documenter toutes les failles prioritaires et obtenir un vrai plan de remédiation.

Audit API & webhooks

Tester la surface OpenAPI, GraphQL, webhooks et endpoints métier trop confiants.