Les bots et l’IA sont depuis longtemps étroitement liés. Les premiers tests CAPTCHA, inventés pour faire barrage aux bots, étaient conçus comme des problèmes faciles à résoudre pour les humains, mais difficiles pour l’IA — une distinction qui remonte à une publication d’Alan Turing datant de 1950 sur l’intelligence informatique. Plus récemment, des entreprises de cybersécurité, dont F5, ont déployé l’IA pour détecter les bots, tandis que les créateurs de bots ont utilisé l’IA pour contourner les systèmes de détection et résoudre les tests CAPTCHA. Avec l’IA générative, les liens entre les bots et l’IA continuent d’évoluer : les bots extraient du contenu d’Internet pour alimenter les grands modèles de langage (LLM), tandis que les agents d’IA — qui sont essentiellement des bots intelligents — interagissent avec les applications de manière imprévue. Cette étroite imbrication entre les bots et l’IA apparaît également lorsque l’on examine le Top 10 des risques et mesures d’atténuation pour les LLM et les applications d’IA générative en 2025.
“Les acteurs malveillants utilisent presque toujours des bots, sous une forme ou une autre, pour mener à grande échelle des cyberattaques contre les grands modèles de langage (LLM). Limiter l’activité des bots revient donc à priver les cybercriminels d’un outil important.”
Les bots ne sont certainement pas le seul moyen d’exploiter les vulnérabilités des LLM. La sécurité des LLM est un domaine complexe de la cybersécurité qui évolue rapidement, et je ne souhaite pas réduire ce défi à une cause ou à une solution unique. Nous savons néanmoins que les acteurs malveillants utilisent presque toujours des bots, sous une forme ou une autre, pour mener des cyberattaques à grande échelle. Par conséquent, lutter contre les bots permet de priver les cybercriminels d’un outil important de leur arsenal. Pour comprendre pourquoi la lutte contre les bots est aussi pertinente pour la sécurité des LLM que pour celle du Web, des applications mobiles et des API, passons en revue les 10 principaux risques de sécurité de l’OWASP pour les LLM en 2025 et examinons comment un acteur malveillant pourrait utiliser des bots pour exploiter chacune de ces vulnérabilités.
1. Injection de prompt
Une attaque par injection de prompt vise à modifier le comportement des LLM de manière malveillante, ce qui, selon l’OWASP, peut amener les modèles « à enfreindre les directives, à générer du contenu préjudiciable, à permettre des accès non autorisés ou à influencer des décisions critiques ». Pour influer sur le comportement des modèles au moyen de prompts, l’adversaire peut être amené à en injecter un grand nombre, submergeant ainsi le modèle de prompts malveillants afin de maximiser les dommages ou de trouver celui qui produira le résultat souhaité. Pour soumettre un nombre suffisamment élevé de prompts malveillants, les adversaires devront recourir à des bots afin d’automatiser le processus.
2. Divulgation d’informations sensibles
Dans la course au développement de grands modèles de langage (LLM) apportant une réelle valeur ajoutée aux employés et aux clients, les organisations entraîneront des modèles sur de vastes ensembles de données qui leur sont propres. Toutefois, ces ensembles peuvent contenir des informations sensibles, notamment des données à caractère personnel et des secrets commerciaux. Il est presque certain que des acteurs malveillants sonderont ces modèles dans l’espoir de divulguer ces données sensibles. Et comme ils ne sauront peut-être pas exactement quelles données rechercher ni comment formuler une requête précise pour les obtenir, ils pourront recourir à une approche par force brute, en envoyant de nombreuses requêtes dans l’espoir que l’une d’elles révèle des informations sensibles de grande valeur. Pour soumettre un grand nombre de requêtes aux modèles, les acteurs malveillants qui cherchent à mener leurs attaques à grande échelle déploieront des bots.
3. Chaîne d’approvisionnement
Comme tout système d’information, les LLM ont des dépendances, notamment les données d’entraînement, les modèles de fondation et les plateformes de déploiement, ce qui signifie que des acteurs malveillants peuvent compromettre un LLM en s’attaquant à sa chaîne d’approvisionnement. Pour compromettre ces dépendances, les acteurs malveillants utiliseront probablement des bots afin d’injecter de fausses informations dans les référentiels de données, de contourner les systèmes d’authentification au moyen du bourrage d’identifiants ou de proxys d’hameçonnage en temps réel, et de rechercher des vulnérabilités dans les mécanismes d’autorisation.
4. Empoisonnement des données et des modèles
Dans le cadre de l’empoisonnement des données, les acteurs malveillants manipulent les données de préentraînement, d’ajustement fin ou d’intégration vectorielle afin d’introduire des vulnérabilités, des portes dérobées ou des biais. Selon l’OWASP, « cette manipulation peut compromettre la sécurité, les performances ou le comportement éthique du modèle, entraînant des résultats préjudiciables ou une altération de ses capacités ». Bien que les acteurs malveillants puissent recourir à de nombreuses méthodes pour manipuler les données, les bots constituent un outil courant dans de nombreux types d’attaques, qu’il s’agisse de contourner les mécanismes d’authentification ou d’autorisation, ou encore d’insérer de fausses données dans des référentiels par l’intermédiaire d’applications dépourvues de protection contre les bots.
5. Traitement incorrect des sorties
La gestion inadéquate des sorties désigne l’absence de vérification visant à déterminer si la sortie d’un modèle de langage de grande taille (LLM) pourrait nuire à un système qui s’appuie sur celle-ci. Alors que les vulnérabilités liées à la chaîne d’approvisionnement et à l’empoisonnement des données et des modèles concernent la compromission de systèmes situés en amont du modèle LLM, la gestion inadéquate des sorties affecte les systèmes en aval, c’est-à-dire ceux qui dépendent des sorties du modèle LLM. Selon OWASP, « l’exploitation réussie d’une vulnérabilité liée à une gestion inadéquate des sorties peut entraîner des attaques de type cross-site scripting (XSS) et falsification de requêtes intersites (CSRF) dans les navigateurs web, ainsi que des falsifications de requêtes côté serveur (SSRF), une élévation de privilèges ou l’exécution de code à distance sur les systèmes back-end. »
Autrement dit, l’adversaire utilise le LLM pour attaquer une autre application qui dépend des résultats qu’il génère. Si un attaquant peut exploiter cette vulnérabilité au moyen d’entrées soigneusement élaborées et soumises à une application, il peut également tenter de mener une attaque par force brute en automatisant l’essai de nombreuses variantes afin de trouver une entrée produisant un résultat nuisible à une application en aval. Le processus automatisé tentera de contraindre le modèle à générer un résultat malveillant, puis vérifiera si celui-ci a eu l’effet néfaste recherché sur l’application. Le déploiement à grande échelle de ce type de sondage nécessitera des bots.
6. Autonomie excessive
Autonomie excessive est une forme d’élévation de privilèges réalisée par l’intermédiaire d’un système basé sur un LLM. Cette vulnérabilité découle du fait qu’un système basé sur un LLM s’exécute avec des privilèges élevés, ce qui lui permet d’appeler des fonctions ou d’interagir avec d’autres systèmes. Ne sachant pas où le système basé sur un LLM dispose de privilèges élevés ni comment exploiter cette élévation, l’attaquant aura probablement recours à l’automatisation pour soumettre de multiples invites, dans l’espoir de déclencher et d’exploiter une élévation de privilèges.
7. Fuite du prompt système
Les applications basées sur des LLM fournissent souvent au modèle des instructions système qui guident son comportement afin de répondre aux exigences de l’application. En pratique, les prompts système peuvent contenir des informations confidentielles : chaînes de connexion à des bases de données, code propriétaire, propriété intellectuelle ou autres contenus que les entreprises doivent protéger. La fuite de prompt système est donc une forme spécifique d’injection de prompt qui amène une application à révéler involontairement ses instructions système.
Amener un LLM à divulguer ces secrets au moyen de prompts n’est pas chose aisée, et il est presque certain que des acteurs malveillants développeront des scripts automatisés afin de rechercher plus efficacement les données sensibles intégrées aux prompts système.
8. Faiblesses des vecteurs et des plongements
Les applications de LLM améliorent souvent les résultats du modèle grâce à un contexte enrichi, fourni aux modèles au moyen d’une technique appelée génération augmentée par récupération (RAG). Le contenu fourni aux LLM via la RAG n’est pas du texte brut, mais plutôt des vecteurs prétraités intégrant des métadonnées et du contenu. Selon l’OWASP, « les faiblesses dans la manière dont les vecteurs et les représentations vectorielles sont générés, stockés ou récupérés peuvent être exploitées par des actions malveillantes (intentionnelles ou non) afin d’injecter du contenu nuisible, de manipuler les résultats du modèle ou d’accéder à des informations sensibles ». Autrement dit, les adversaires peuvent cibler le contenu RAG et son traitement pour attaquer le système de LLM.
Les entreprises mettent en œuvre leurs propres processus et définissent le périmètre du contenu RAG afin de répondre aux besoins spécifiques de leur organisation. Le contenu et ses failles seront donc propres à chaque organisation. Du point de vue d’un adversaire, il ne sera pas facile de découvrir ces failles, ce qui nécessitera certainement une exploration automatisée, autrement dit le recours à des bots.
9. Désinformation
Lorsque les LLM produisent des informations fausses ou trompeuses, les systèmes qui s’appuient sur ces informations peuvent dysfonctionner, entraînant des failles de sécurité, une atteinte à la réputation et une responsabilité juridique. Les LLM peuvent générer de fausses informations en raison d’hallucinations, de biais ou de lacunes dans les données d’entraînement.
Les acteurs malveillants cherchant à exploiter les hallucinations automatiseront probablement la soumission de leurs requêtes et l’analyse des réponses. Par exemple, en automatisant le processus de génération de code, c’est-à-dire en utilisant un LLM pour produire de nombreux extraits de code informatique, ils peuvent repérer des références à des bibliothèques logicielles qui n’existent pas réellement. Ils peuvent alors créer une bibliothèque logicielle malveillante dans le dépôt de code que le LLM a inventé. Si le code généré par le LLM ne fait pas l’objet d’un examen adéquat, la bibliothèque malveillante sera intégrée au produit publié.
De même, les adversaires peuvent utiliser des bots pour manipuler les données d’entraînement en injectant délibérément d’énormes volumes de données destinées à biaiser le modèle.
10. Consommation illimitée
La dixième vulnérabilité OWASP liée aux LLM, « consommation sans limites », correspond étroitement à la vulnérabilité des API répertoriée par l’OWASP sous le nom de « consommation illimitée des ressources », ainsi qu’à la menace automatisée appelée « déni de service ». L’attaquant dépasse le nombre de requêtes prévu au point que le service d’inférence subit un déni de service, une dégradation des performances et des coûts excessifs. Selon l’OWASP, « les besoins élevés en ressources de calcul des LLM, en particulier dans les environnements cloud, les rendent vulnérables à l’exploitation des ressources et à une utilisation non autorisée ». Pour dépasser le niveau d’utilisation prévu, les attaquants auront presque certainement recours à des bots afin d’augmenter le volume de requêtes.
Mise en œuvre de protections contre les bots
Alors que de nombreuses organisations sont contraintes d’accélérer la mise sur le marché de fonctionnalités d’IA et que les implications des LLM en matière de sécurité ne sont pas encore pleinement comprises, elles devraient envisager de mettre en place des protections contre les bots en amont des applications basées sur des LLM, ainsi que des applications qui alimentent les modèles LLM en données. Plus les adversaires peuvent lancer d’attaques, plus leurs chances de réussite sont élevées. F5 propose un service de protection contre les bots particulièrement efficace, F5 Distributed Cloud Bot Defense, lui-même basé sur l’IA, qui aide les organisations à prendre l’avantage sur les adversaires utilisant des bots et l’automatisation pour cibler les applications LLM.
En savoir plus sur Distributed Cloud Bot Defense.
À propos de l’auteur
Articles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.