Plugins de chatbot web : comment des widgets non sécurisés amplifient l'injection de prompt

De quoi s’agit-il ?

La recherche sur l’injection de prompt vise le plus souvent les assistants de pointe — copilotes, agents de code, pipelines RAG. Mais l’application LLM la plus répandue sur le web est bien plus simple : la bulle de chatbot de service client dans le coin d’un site marchand ou SaaS. Un article intitulé « When AI Meets the Web: Prompt Injection Risks in Third-Party AI Chatbot Plugins », déposé sur arXiv le 8 novembre 2025 et accepté à IEEE S&P 2026, est la première analyse à grande échelle de cette surface. Signé par Yigitcan Kaya, Anton Landerer, Stijn Pletinckx, Michelle Zimmermann, Christopher Kruegel et Giovanni Vigna (UC Santa Barbara), il étudie 17 plugins de chatbot tiers déployés sur plus de 10 000 sites web publics et montre que c’est la tuyauterie autour du LLM — et non le modèle lui-même — qui pose problème.

Comment ça marche

Ces plugins servent d’intermédiaires entre un créateur de site non expert et une API LLM commerciale. L’étude documente deux faiblesses structurelles.

La première est l’intégrité de l’historique de conversation. Dans un échange normal, chaque requête vers le LLM renvoie les tours précédents pour fournir le contexte. Les chercheurs constatent que 8 plugins (utilisés sur environ 8 000 des sites étudiés) font confiance à l’historique envoyé par le navigateur sans le vérifier côté serveur. Un attaquant qui contrôle sa propre session peut modifier cette charge utile avant qu’elle ne quitte le navigateur — en falsifiant des réponses antérieures de l’assistant, voire des faux messages système que le modèle traite comme faisant autorité. Avec un historique fabriqué affirmant que l’assistant a déjà accepté d’abandonner ses règles, une injection directe devient bien plus efficace : l’article mesure une hausse de 3 à 8x du taux de réussite pour obtenir des comportements non désirés, comme la génération de code.

La seconde est le mélange de contenus non fiables. 15 des 17 plugins proposent des outils — le scraping web en particulier — pour enrichir le contexte du chatbot avec le contenu du site. Mais ils ne font aucune distinction entre le contenu de confiance que le propriétaire contrôle (descriptions produit, politiques) et le contenu tiers non fiable (avis clients, Q&R, commentaires). Tout ce qui est scrapé arrive dans le prompt avec la même autorité, ce qui constitue le scénario type de l’injection de prompt indirecte : un avis malveillant peut porter des instructions que le chatbot exécute ensuite. Les auteurs ont trouvé qu’environ 13 % des sites e-commerce étudiés avaient déjà connecté leur chatbot à du contenu tiers, exposant la surface avant même qu’un attaquant ne se présente.

Pourquoi c’est important

L’enseignement central : les garde-fous des LLM ne survivent pas à une mauvaise intégration. Les modèles commerciaux sous-jacents sont livrés avec un alignement et un entraînement au refus, mais un plugin non sécurisé tend aux attaquants les leviers — historique falsifié, contexte non segmenté — qui contournent ces défenses. Parce que la même poignée de plugins est réutilisée sur des milliers de sites, un seul motif non sécurisé se démultiplie en une longue traîne de déploiements vulnérables, gérés par des propriétaires qui n’ont écrit aucune ligne de l’intégration. C’est le milieu de marché ingrat : pas un agent vedette, mais le chatbot que les utilisateurs ordinaires manipulent réellement.

Défenses

Imposez l’intégrité de l’historique côté serveur. Ne faites jamais confiance à l’historique de messages (et surtout aux rôles système ou assistant) rejoué depuis le client. Reconstruisez ou authentifiez la session côté serveur, signez ou stockez la transcription canonique, et rejetez d’emblée tout message système fourni par le client. Ce seul contrôle supprime l’amplification de 3 à 8x mesurée par l’article.

Séparez contenu de confiance et contenu non fiable dans le prompt. Traitez les avis scrapés, commentaires et tout texte tiers comme des données, pas des instructions. Encadrez-les avec des délimiteurs clairs, étiquetez leur provenance et — quand le plugin le permet — appliquez du spotlighting ou un filtre d’entrée avant qu’ils n’atteignent le modèle. Le contenu contrôlé par le propriétaire et celui contrôlé par les visiteurs ne doivent pas partager le même niveau d’autorité. Cela correspond directement aux recommandations OWASP LLM01 : Prompt Injection.

Limitez le rayon d’impact. Donnez au chatbot la capacité minimale nécessaire : aucun appel d’outil, exécution de code ou accès à des données sensibles dont il n’a pas besoin pour le support. Ajoutez un filtrage des sorties à risque (code, liens, commandes) et surveillez les invocations d’outils anormales plutôt que de compter sur le refus du modèle.

Si vous exploitez un site équipé d’un tel widget, vérifiez si votre chatbot scrape du contenu généré par les utilisateurs et demandez à votre fournisseur comment l’historique de conversation est validé. Le correctif se situe dans la couche d’intégration — précisément là où la plupart des propriétaires supposent que le fournisseur s’en est chargé.

Statut

Élément	Détail
Source	arXiv:2511.05797, « When AI Meets the Web », déposé le 2025-11-08 ; à IEEE S&P 2026
Périmètre	17 plugins de chatbot tiers sur plus de 10 000 sites web publics
Constat 1	8 plugins (~8 000 sites) sans intégrité d’historique → injection directe 3 à 8x plus forte
Constat 2	15 plugins mélangent contenu fiable/non fiable via des outils → injection indirecte ; ~13 % des sites e-commerce déjà exposés
Cause racine	Pratiques d’intégration non sécurisées, pas le LLM sous-jacent
Action	Intégrité d’historique côté serveur ; séparation contenu fiable/non fiable ; chatbots à capacité minimale