Prompt Injection dans les chatbots de site web : protection pour le RAG, les outils et les données

Un chatbot de site web ne traite pas uniquement des questions inoffensives. Les visiteurs peuvent tenter de réécrire ses règles, de révéler des instructions internes ou de déclencher des actions non autorisées. Plus difficiles encore à détecter sont les instructions qui ne se trouvent pas directement dans le chat, mais qui sont dissimulées dans une page web explorée, un document téléversé ou un système tiers connecté.

Pour limiter la prompt injection dans les chatbots de site web, on ne peut donc pas compter uniquement sur un prompt système rédigé de manière particulièrement stricte. Une architecture multicouche est nécessaire : les entrées et les sources sont traitées comme non fiables, les autorisations sont restreintes sur le plan technique, les sorties sont vérifiées avant tout traitement ultérieur et les actions à risque sont confirmées par du code déterministe ou par un être humain.

Ce que signifie la prompt injection pour un chatbot de site web

L'OWASP décrit la prompt injection comme une entrée qui modifie involontairement le comportement ou la sortie d'un modèle linguistique. Une prompt injection directe provient directement de l'utilisateur, par exemple sous la forme d'une incitation à ignorer les règles précédentes. Une prompt injection indirecte se cache en revanche dans des contenus externes que le système consulte ultérieurement : pages web, documents de connaissances, e-mails, données produits ou fichiers.

Cette distinction est essentielle pour les exploitants de sites web. Un simple chatbot FAQ présente une surface d'attaque bien plus réduite qu'un système qui explore continuellement des pages web, parcourt des documents internes, lit des données CRM ou exécute des fonctions. La génération augmentée de récupération (Retrieval-Augmented Generation, ou RAG) améliore certes la pertinence métier des réponses, mais n'élimine pas le risque d'injection. Même un corpus de sources bien entretenu peut contenir des instructions manipulées ou mal interprétées.

Évaluer le risque en fonction des fonctionnalités plutôt que du nom du modèle

La question décisive n'est pas seulement « Quel modèle utilisons-nous ? », mais plutôt « Quelle portée peut avoir une réponse manipulée ? ». Établissez une cartographie simple des fonctionnalités et des données pour votre chatbot :

• Quelles sources publiques et internes est-il autorisé à lire ?
• Quelles données personnelles, confidentielles ou critiques pour l'entreprise sont accessibles ?
• Peut-il uniquement générer du texte ou peut-il aussi créer des tickets, des leads, des e-mails, des rendez-vous ou des commandes ?
• Quelles actions modifient des systèmes externes ?
• Quelles décisions sont appliquées automatiquement sans vérification humaine ?

Plus les droits de lecture, les droits d'écriture et le niveau d'automatisation augmentent, plus les limites techniques extérieures au modèle deviennent cruciales. L'aperçu existant sur les erreurs courantes des chatbots IA aide à réaliser un état des lieux général. Pour la prompt injection, vous devez en outre documenter les flux de données, les frontières de confiance et les droits d'action.

Séparer clairement quatre zones de confiance

Un modèle de sécurité pratique distingue quatre zones, même si elles sont techniquement traitées au sein de la même application.

Zone 1 : Règles système et directives

C'est ici que sont définis le rôle, l'objectif autorisé, les limites de réponse et les règles d'escalade. Ces règles guident le modèle, mais ne constituent pas un contrôle d'accès fiable. L'OWASP met expressément en garde contre le fait de traiter les prompts système comme un secret ou un mécanisme de sécurité. Les identifiants de connexion, clés API et informations internes sensibles ne doivent pas s'y trouver.

Zone 2 : Entrées des visiteurs

Chaque message du chat doit être considéré comme non fiable. Limitez la longueur, les types de fichiers et les fonctions autorisées ; normalisez les entrées pour le traitement technique et identifiez-les clairement comme des données utilisateur dans le prompt. Un filtre peut détecter des schémas d'attaque connus, mais ne doit pas bloquer arbitrairement des questions légitimes. Un visiteur qui recherche « ignore previous instructions » dans une documentation de sécurité peut avoir une demande parfaitement légitime.

Zone 3 : Sources récupérées et contexte RAG

De même, les contenus explorés, les PDF et les résultats de services externes restent des données, et non des instructions. Séparez visiblement leur contenu du contexte de commande, enregistrez la provenance ainsi que l'horodatage de récupération, et n'autorisez que des sources validées. L'article sur l'actualisation de la base de connaissances d'un chatbot IA montre comment interagissent inventaire des sources, fréquence d'exploration et assurance qualité.

Zone 4 : Outils, actions et sorties

Les appels de fonction ne doivent pas être exécutés du seul fait que le modèle génère le texte correspondant. Un contrôleur déterministe vérifie le nom de la fonction, les paramètres, les autorisations, le contexte de session et les systèmes cibles autorisés. Les sorties du modèle ultérieurement utilisées comme HTML, Markdown, SQL, chemin de fichier ou paramètre d'API nécessitent la validation et le codage adaptés à ce contexte.

Le principe du moindre privilège limite l'impact

En l'état actuel des connaissances, la prompt injection ne peut pas être exclue de manière totalement fiable par une mesure unique. L'application doit donc être conçue de sorte qu'une tentative de manipulation réussie ait un impact aussi limité que possible. L'OWASP et Microsoft recommandent pour cela d'appliquer le principe du moindre privilège.

• Utilisez des identités techniques distinctes pour la lecture et l'écriture.
• N'accordez l'accès qu'aux données strictly nécessaires à l'objectif spécifique du chatbot.
• Limitez les fonctions à des schémas de paramètres réduits et clairement définis.
• Utilisez des autorisations à durée de vie courte lorsqu'une action en nécessite.
• Exigez une confirmation explicite pour les actions risquées ou irréversibles.
• Ne confiez jamais l'autorisation au texte libre généré par le modèle.

Un chatbot de support peut par exemple préparer un brouillon de ticket, mais ne devrait pas déterminer automatiquement des destinataires, des priorités ou des droits d'accès internes arbitraires. Un chatbot de génération de leads peut recueillir des coordonnées structurées sans pour autant obtenir des droits de lecture sur l'ensemble du CRM.

Vérifier et isoler les sources RAG

La prompt injection indirecte fait du pipeline de sources un élément à part entière de l'architecture de sécurité. Une page manipulée peut sembler inoffensive à l'œil nu tout en contenant du texte interprété par le modèle comme une instruction. Dans les systèmes multimodaux, les images ou d'autres formats de fichiers peuvent également jouer un rôle.

Mettez donc en place une gestion des entrées de sources assortie de règles de validation : domaines et sections de documents autorisés, propriétaires identifiables, gestion des versions, analyse antivirus et vérification des fichiers, ainsi qu'une revue pour les contenus nouveaux ou modifiés de manière inhabituelle. Marquez explicitement les passages récupérés dans le contexte du modèle comme non fiables (untrusted content). Un résultat de recherche peut fournir des informations, mais ne doit en aucun cas modifier les règles système ou les autorisations d'outils.

Vérifiez également si la réponse est réellement appuyée par les sources. Le guide sur la qualité des réponses des chatbots IA avec Golden Set et tests RAG décrit la fidélité aux sources (groundedness) et la vérification documentaire. Ce contrôle qualité complète les contrôles de sécurité, mais ne les remplace pas.

Les filtres d'entrée et de sortie sont une couche, pas la solution globale

Des services de protection spécialisés peuvent détecter les tentatives d'attaque directes et indirectes. Par exemple, Microsoft Prompt Shields distingue les attaques dans les entrées utilisateur des instructions cachées dans les documents. Google recommande également dans ses directives de sécurité des mesures de protection contre la prompt injection, des tâches plus strictly délimitées, des identifiants utilisateur, des limitations de débit et une supervision humaine en cas de risque élevé.

De tels filtres fournissent des signaux probabilistes. Prévoyez donc un comportement gradué : bloquer, répondre de manière sécurisée, passer à un mode restreint ou passer le relais à un être humain. Journalisez la catégorie de décision et la version technique, tout en évitant le stockage inutile du texte intégral. Pour les données personnelles, s'appliquent en outre les domaines de contrôle décrits dans l'article sur les chatbots IA et le RGPD. Cet article ne constitue pas un conseil juridique.

Valider les sorties du modèle avant tout traitement ultérieur

Une entrée sécurisée ne garantit pas une sortie sécurisée. L'OWASP classe le traitement insuffisant des sorties comme un risque à part entière : le texte généré par le modèle peut ensuite se retrouver dans du HTML, des scripts, des requêtes de base de données ou des chemins de fichiers. Traitez donc également chaque sortie du modèle comme non fiable a priori.

Pour les flux automatisés, exigez un format structuré strict et validez-le par rapport à un schéma. Utilisez des listes autorisées (whitelists) pour les noms de fonctions et les systèmes cibles. Encodez le texte visible selon le contexte d'affichage respectif. Rejetez les champs inattendus, les URL externes et les paramètres hors des valeurs autorisées. Les données sensibles doivent faire l'objet d'un contrôle de conformité spécifique avant tout affichage ou transmission.

Tester la prompt injection avec un jeu de tests de sécurité

Complétez votre Golden Set métier par des cas de test adversariaux. Ces tests doivent évaluer l'ensemble du système en production, y compris la récupération d'informations, les outils et la logique d'autorisation, et non pas seulement le modèle de base. Un jeu de tests efficace comprend :

• des tentatives directes de remplacer des règles ou d'extraire des instructions internes ;
• des variantes multilingues, encodées ou réparties sur plusieurs messages ;
• des questions métier inoffensives contenant des mots-clés similaires, qui ne doivent pas être bloquées à tort ;
• des passages manipulés au sein d'une source de connaissances de test ;
• des noms de fonctions non autorisés, des paramètres supplémentaires et des adresses cibles externes ;
• des tentatives de divulgation de données confidentielles ou du contenu de sessions antérieures ;
• des tests sur les sorties au format HTML, Markdown ou liens ;
• des parcours d'annulation, de transfert à un humain et de confirmation pour les actions à risque.

Ne mesurez pas uniquement le déclenchement d'un filtre. Évaluez le résultat final : une action non autorisée a-t-elle été empêchée ? Les données confidentielles sont-elles restées protégées ? Une requête légitime a-t-elle continué à fonctionner normalement ? Un cas suspect a-t-il été journalisé de manière traçable ?

Plan de mise en œuvre pratique pour les équipes web

1. Délimiter le périmètre : documenter les sources de données, les outils, les droits d'écriture et les cibles externes.
2. Séparer les zones de confiance : identifier techniquement les règles système, les entrées utilisateur, le contenu RAG et les sorties d'action.
3. Réduire les privilèges : supprimer les accès inutilisés et décomposer les actions d'écriture en fonctions restreintes.
4. Ajouter des validations : mettre en place des limites d'entrée, des sorties structurées, des listes autorisées et un encodage adapté au contexte.
5. Définir les validations humaines : sécuriser les actions à risque et les flux de données sensibles via une validation humaine (Human-in-the-loop).
6. Exécuter le jeu de tests : tester les cas de contrôle directs, indirects et légitimes avant chaque mise en production importante.
7. Surveiller l'exploitation : examiner régulièrement les événements de filtrage, les actions refusées, les modifications de sources inhabituelles et les faux positifs.

Liste de contrôle : protection contre la prompt injection

• Le prompt système ne contient aucun secret et ne remplace pas l'autorisation.
• Les textes d'utilisateurs et les sources externes sont considérés comme non fiables par défaut.
• Les sources RAG possèdent une validation, une provenance, une version et des propriétaires responsables.
• Les outils respectent le principe du moindre privilège et n'acceptent que des paramètres validés.
• Les actions à risque nécessitent une confirmation traçable.
• Les sorties du modèle sont vérifiées avant leur envoi vers le HTML, l'API, le CRM ou d'autres systèmes cibles.
• Les filtres de sécurité sont évalués en mesurant les faux positifs et les faux négatifs.
• Des tests d'attaques directes et indirectes sont exécutés régulièrement et après chaque modification.

Conclusion

La prompt injection n'est pas un simple problème d'ingénierie de prompt. Pour les chatbots de site web, une protection robuste n'émerge que lorsque l'application traite les entrées, les sources, les sorties et les actions comme des zones de confiance distinctes. Les filtres peuvent détecter les attaques, mais le principe du moindre privilège, la validation déterministe et la validation humaine sont ce qui en limite réellement l'impact potentiel.

Commencez par la cartographie des fonctionnalités et des données de votre chatbot. Supprimez les privilèges inutiles, isolez les contenus RAG et testez l'ensemble du parcours jusqu'à l'action externe. Votre chatbot reste ainsi utile sans qu'un texte libre généré par un modèle ne décide des autorisations ou de modifications critiques pour l'entreprise.

Sources

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance