Red teaming LLM vs test d'intrusion d'application web : ce que chacun couvre, le coût et quand vous avez besoin des deux

Il s’agit des fourchettes indicatives publiées sur notre page des services de cybersécurité. Le prix final dépend du périmètre, et chaque mission commence par la définition de ce qui est inclus et de ce qui est exclu.

Ce que couvre un test d’intrusion d’application web

Un test d’intrusion d’application web est une tentative autorisée de pénétrer dans votre application en production, selon une approche boîte noire, boîte grise ou boîte blanche, en fonction du niveau d’accès accordé aux testeurs. La couverture type correspond à l’OWASP Top 10 : contrôle d’accès défaillant, injection, défaillances d’authentification, configuration non sécurisée, composants vulnérables et problèmes similaires.

Il répond à des questions telles que : un client peut-il lire les données d’un autre, un utilisateur ordinaire peut-il accéder aux fonctions d’administration, une saisie peut-elle sortir de son usage prévu, des secrets ou des interfaces de débogage sont-ils exposés ? Le résultat est un rapport écrit présentant des constats démontrés, leur gravité et des conseils de remédiation, et il doit inclure un nouveau test après la correction des problèmes identifiés.

Si vous en êtes à une étape plus précoce et souhaitez savoir quel type d’examen vous convient, consultez notre comparatif des audits techniques, tests d’intrusion et revues de code.

Ce que couvre le red teaming de LLM

Le red teaming de LLM considère le modèle, et tout ce qui y est connecté, comme la cible. Les principaux types d’attaques sont les suivants :

• Injection de prompt directe : un utilisateur rédige des instructions visant à contourner votre prompt système (« ignore tes instructions précédentes »).
• Injection de prompt indirecte : des instructions hostiles dissimulées dans une page web, un document, un e-mail ou un résultat d’outil que le modèle lit pour le compte d’un utilisateur.
• Jailbreaks : faire franchir au modèle ses limites de sécurité et de politique d’usage.
• Extraction de données : amener le modèle à révéler son prompt, les données d’autres utilisateurs ou du contenu sur lequel il a été entraîné ou qu’il récupère.
• Déni de service du modèle : des prompts conçus pour consommer une puissance de calcul ou un budget excessifs.
• Empoisonnement de la récupération : insérer du contenu dans les documents consultés par votre système de récupération (RAG) afin que le modèle le répète ou agisse en conséquence.
• Mauvais usage des outils par un agent : convaincre un agent d’appeler un outil puissant, comme l’envoi d’e-mails, l’émission de remboursements ou la suppression d’enregistrements, avec des entrées contrôlées par l’attaquant.
• Élévation de périmètre via des serveurs MCP et des plugins : utiliser un outil connecté pour accéder à des données ou à des actions auxquelles l’utilisateur ne devrait pas avoir droit.
• Risques liés à la chaîne d’approvisionnement : prompts, modèles ou outils tiers malveillants.

Le rapport indique lesquelles de ces attaques fonctionnent contre votre produit, comment un attaquant les enchaînerait et ce qu’il faut modifier. De nombreux produits d’IA en production en exposent plusieurs à la fois, souvent parce que chaque fonctionnalité était raisonnable prise isolément.

Où les deux se recoupent

Le recoupement est plus important qu’il n’y paraît. Dès qu’un agent d’IA peut appeler des outils, une injection de prompt devient un problème de contrôle d’accès : le modèle est un nouvel utilisateur, facile à convaincre, au sein de votre système. S’il peut lire les dossiers d’un client ou déclencher un paiement, tout ce qu’un test d’intrusion web vérifie sur les permissions s’applique désormais aussi à ce que le modèle est autorisé à faire.

Cela fonctionne aussi dans l’autre sens. La sortie du modèle est un texte non fiable. Si votre interface l’affiche sans précaution, une vulnérabilité web classique comme le cross-site scripting peut arriver par le modèle. Un bon red team inclura des vérifications conventionnelles sur ces chemins.

Avez-vous besoin de l’un ou des deux ?

• Une application web ordinaire sans fonctionnalité d’IA : un test d’intrusion d’application web, une fois les bases corrigées.
• Un chatbot qui ne répond qu’à partir de contenu public : risque plus faible, mais testez la fuite de prompt, les abus et les limites de coûts, et vérifiez aussi la couche web.
• Un assistant ayant accès à des données privées ou clients : les deux. L’exposition de données via le modèle est la défaillance la plus coûteuse à expliquer.
• Un agent qui exécute des actions via des outils ou des serveurs MCP : les deux, avec les permissions des outils comme point central.
• Un produit de récupération (RAG) sur de nombreuses sources : les deux, avec une attention particulière à qui peut ajouter des documents à l’index.

Lorsque le budget est serré, commencez par lister trois éléments : les données que le modèle peut voir, les actions qu’il peut exécuter et les personnes qui peuvent lui parler. Plus il y en a, plus les tests sont urgents.

Réduire le risque avant de tester

L’injection de prompt ne peut pas être totalement éliminée aujourd’hui ; une bonne conception part donc du principe que le modèle sera parfois trompé et en limite les dégâts :

1. Accordez aux outils le moindre privilège possible et limitez leur périmètre par utilisateur, jamais avec une seule clé partagée très puissante.
2. Exigez une confirmation humaine pour les actions destructrices ou à forte valeur.
3. Traitez la sortie du modèle comme non fiable et validez-la ou encodez-la avant qu’elle n’atteigne une interface, une base de données ou un autre système.
4. Séparez les instructions du contenu non fiable lorsque votre architecture le permet, et évitez de placer des secrets dans les prompts.
5. Journalisez les appels d’outils et définissez des limites de débit et de dépenses afin que les abus soient visibles et bornés.

Intégrer ces mesures dès le départ coûte bien moins cher que de les ajouter après un constat. C’est l’approche que nous adoptons lorsque nous développons des agents d’IA et des serveurs MCP.

À quoi s’attendre d’une mission

Un prestataire crédible convient du périmètre et des règles d’engagement dès le départ, ne teste que ce que vous autorisez et livre un rapport écrit destiné à la fois aux ingénieurs et aux décideurs. Les corrections doivent être suivies d’un nouveau test afin que vous puissiez démontrer qu’elles fonctionnent. Méfiez-vous de quiconque promet que votre produit d’IA sera « entièrement sécurisé » ; le résultat honnête est une vision plus claire, moins de chemins exploitables et des preuves que vous pouvez partager avec vos clients.

Pour les applications créées par IA qui approchent du lancement, l’ordre que nous suggérons généralement est un audit technique, puis des corrections, puis des tests formels. Notre checklist de préparation à la production est un bon point de départ.