Assistant IA et SSRF : contrôler les URL téléchargées

Cet article s’adresse aux équipes qui ajoutent un assistant IA à une application métier (extranet client, back-office, outil interne) et qui laissent l’utilisateur joindre un document par lien. Dans ce cas, c’est le serveur de l’application qui télécharge le fichier avant de le transmettre au modèle. Ce fonctionnement expose à une faille connue, la SSRF (Server-Side Request Forgery, ou requête forgée côté serveur), dès que personne ne contrôle l’adresse demandée. Vous verrez comment une pièce jointe par URL devient une SSRF dans un assistant IA, puis les contrôles à mettre en place côté code et côté réseau, et comment tester votre application.

Le sujet est concret : le 30 septembre 2026, le paquet laravel/ai a publié un avis de sécurité pour ce cas précis, corrigé par la version 1.0.1 sortie la veille. Les contrôles décrits ici valent pourtant pour n’importe quel assistant, quel que soit le langage ou le SDK.

Comment une pièce jointe par URL devient une faille SSRF

Pour joindre un document à une conversation, il existe deux méthodes. Soit le navigateur envoie le fichier lui-même, en upload classique. Soit il envoie seulement une URL, et le serveur va chercher le fichier. Plusieurs SDK de chat côté navigateur prévoient ce second format : un message peut contenir une « partie » de type fichier avec un champ url au lieu du contenu. C’est pratique, parce que le front n’a pas d’upload à gérer et qu’on peut pointer un document déjà en ligne.

La difficulté vient de l’origine de la requête : elle part du serveur applicatif, pas du poste de l’utilisateur. Or ce serveur joint des adresses que l’utilisateur ne voit pas : localhost, le réseau privé de l’hébergeur, des services internes laissés sans mot de passe parce qu’ils sont « derrière le pare-feu », et sur beaucoup de clouds un service de métadonnées à l’adresse 169.254.169.254. Si le code télécharge l’URL sans vérifier ni le schéma, ni l’adresse de destination, ni les redirections, un utilisateur peut lui faire lire ces adresses.

Dans un assistant IA, la conséquence est plus directe que dans une SSRF classique, où l’attaquant ne voit pas toujours la réponse. Ici, le contenu téléchargé est transmis au modèle comme pièce jointe, et le modèle peut le citer ou le résumer dans sa réponse ; l’avis de laravel/ai le précise. Selon ce que le serveur peut joindre, cela va d’une page sans intérêt à un tableau de bord d’administration, un moteur de recherche interne ou des identifiants temporaires du compte cloud. Le modèle se contente de lire ce qu’on lui fournit : la correction se fait dans le code qui télécharge le fichier. La même logique s’applique aux outils qu’on branche sur un agent, comme expliqué dans brancher une IA sur les outils métier.

Qui est concerné par le correctif laravel/ai 1.0.1

D’après l’avis, la faille touche les applications qui exposent à des clients non fiables l’un des deux adaptateurs de chat de laravel/ai : celui du Vercel AI SDK ou celui d’AG-UI. Les deux sont apparus en version 1.0.0 et aucune version 0.x n’est concernée. La version 1.0.1 ajoute un contrôle des URL distantes : seuls http et https sont acceptés, les adresses de boucle locale, privées, link-local, CGNAT et réservées sont bloquées, chaque redirection est revérifiée et la connexion est fixée sur l’adresse vérifiée, ce qui empêche un changement de résolution DNS entre la vérification et la requête.

Si la mise à jour ne peut pas être faite tout de suite, l’avis propose de rejeter les parties fichier contenant une URL avant qu’elles n’atteignent l’adaptateur, ou de bloquer le trafic sortant du serveur vers les adresses internes et de métadonnées.

Les contrôles à mettre en place dans le code

Pour un assistant maison ou un autre SDK, la liste suivante reprend ces protections, de la plus simple à la plus fine :

• Préférer l’upload. Si le besoin métier ne l’exige pas, refusez les pièces jointes par URL : le navigateur envoie le fichier et le serveur ne télécharge plus rien de lui-même. C’est le contrôle le plus simple à vérifier.
• Restreindre les domaines. Si l’URL est nécessaire, une liste de domaines autorisés (votre GED, votre stockage de fichiers) protège mieux qu’un filtre d’adresses, au prix d’une fonctionnalité plus étroite.
• N’accepter que http et https. Les autres schémas n’ont aucune raison d’être téléchargés par un assistant.
• Bloquer les adresses internes après résolution DNS. Le filtre porte sur l’adresse IP réelle, pas sur le nom : un domaine public peut pointer vers 127.0.0.1.
• Revérifier chaque redirection. Une URL publique peut renvoyer une redirection 302 vers une adresse interne. Chaque étape doit passer le même contrôle, et la connexion doit partir vers l’adresse vérifiée.
• Tenir les dépendances à jour. composer audit en intégration continue signale les paquets qui ont reçu un avis de sécurité, comme celui-ci. Relire ce qui change dans les dépendances fait partie du même travail (voir relire le diff de vendor).

Les contrôles côté réseau et hébergement

Ces protections limitent les dégâts même si un nouveau point d’entrée apparaît dans le code. Le serveur applicatif ne devrait pas pouvoir joindre le service de métadonnées ni les plages privées dont il n’a pas besoin : une règle de pare-feu sortante suffit souvent. Sur AWS, exiger IMDSv2 oblige à obtenir un jeton par une requête PUT avant de lire les métadonnées, ce qu’un simple GET forgé ne sait pas faire. D’autres clouds exigent un en-tête spécifique sur leur service de métadonnées, ce qui bloque aussi un GET brut, mais ne protège pas les autres services internes.

Le filtrage des adresses privées a une limite : il ne sert à rien si le service sensible est public mais réservé à l’IP du serveur, par exemple une API partenaire filtrée par adresse IP. Dans ce cas, seule la liste de domaines autorisés protège vraiment.

Tester votre assistant avant et après la correction

Ces tests se font sur un environnement de recette, jamais en production :

1. Envoyez une partie fichier qui pointe vers une URL publique dont vous lisez les journaux. Si une requête arrive avec l’IP du serveur applicatif, l’application télécharge bien les URL fournies par le client.
2. Pointez une URL vers un service interne inoffensif de la recette, par exemple une page de statut sur 127.0.0.1. Si la réponse de l’assistant reprend ce contenu, le filtrage des adresses manque.
3. Pointez une URL publique qui redirige vers cette même adresse interne. Si le contenu remonte, seule la première URL est contrôlée.

Une fois la correction en place, un test automatisé peut envoyer une URL vers 127.0.0.1 au point d’API du chat et attendre un refus, pour que le contrôle ne disparaisse pas au prochain refactoring. Si le premier test ne montre aucune requête entrante alors que l’assistant renvoie du contenu interne, la fuite vient d’ailleurs : un document sensible indexé dans la base documentaire, un outil appelé avec des droits trop larges, ou des consignes cachées dans un document qui poussent l’agent à appeler cet outil.

Les autres endroits où votre serveur télécharge une URL

Le même mécanisme existe hors de l’IA : import de catalogue par URL, avatar récupéré depuis un lien, aperçu de lien dans une messagerie, URL de webhook saisie par un client. La liste de contrôles ci-dessus s’applique à chacun. Le plus efficace est de commencer par recenser ces endroits dans l’application, puis de faire passer tous les téléchargements par une fonction unique qui applique ces contrôles.

Ce qu’il faut retenir

• Une pièce jointe par URL fait télécharger le fichier par votre serveur, qui voit votre réseau interne.
• Dans un assistant IA, le contenu téléchargé peut revenir à l’utilisateur dans la réponse du modèle.
• Les applications qui exposent les adaptateurs Vercel AI SDK ou AG-UI de laravel/ai doivent passer en 1.0.1 ou une version plus récente.
• Upload plutôt qu’URL, domaines autorisés, schémas http/https, adresses internes bloquées après résolution DNS, redirections revérifiées, trafic sortant filtré.
• Trois tests en recette suffisent à savoir si votre assistant est exposé.

Si vous branchez un assistant IA sur vos outils métier et voulez savoir ce que votre serveur accepte de télécharger pour lui, c’est le type de vérification que je fais dans mes missions d’intégration IA et MCP.