Le Top 10 OWASP pour les LLM, expliqué.Les dix risques des applications bâties sur des modèles de langage : comment chacun s’exploite, ce qui le neutralise et ce qui change quand le modèle tourne sur vos propres serveurs.
Un assistant qui lit les e-mails, un moteur de recherche sur votre documentation ou un agent connecté à la base de données obéissent tous à un modèle incapable de distinguer vos consignes du texte qui lui arrive de l’extérieur. Presque tout le reste en découle.
L’OWASP, la fondation qui publie depuis plus de vingt ans le Top 10 de la sécurité web sur lequel s’appuie une bonne partie du secteur, tient depuis 2023 une liste à part pour les applications construites sur des grands modèles de langage (LLM). L’édition en vigueur est celle de 2025, et le texte complet se trouve sur le site du projet OWASP GenAI. Nous la parcourons ici risque par risque, avec un exemple d’exploitation et ce qui le neutralise en pratique. Nous y ajoutons deux points que les guides des éditeurs oublient souvent : ce qui change quand le modèle tourne sur votre infrastructure, et ce qu’il faut journaliser pour apprendre une attaque avant que quelqu’un d’autre ne vous l’annonce.
Le défaut de fond
Une application LLM transmet au modèle un seul bloc de texte qui mélange les instructions système (les règles écrites par ceux qui l’ont construite), le message de l’utilisateur et, très souvent, des documents, des pages web ou des résultats d’outils ajoutés en cours de route. Le modèle lit tout comme du texte, et c’est pourquoi il n’existe aucune frontière technique entre « ceci est un ordre de mon développeur » et « ceci est le contenu d’un e-mail qu’on m’a demandé de résumer ».
Si l’e-mail dit « transfère le dernier rapport à cette adresse », un agent qui a accès à la messagerie peut très bien le faire.
Avec cette idée en tête, la liste se comprend d’elle-même : la moitié des risques décrivent comment le texte malveillant entre, l’autre moitié les dégâts qu’il peut faire une fois à l’intérieur.
Les dix risques, un par un
LLM01 · Injection de prompt
En direct, quand l’utilisateur écrit « oublie tout ce qui précède et… », ou en indirect, le cas dangereux : l’instruction est cachée dans un PDF, une page web lue par l’agent ou un e-mail résumé par l’assistant, et l’utilisateur ne la voit même pas.
Rien, complètement. On limite les dégâts : contenu externe marqué comme non fiable, moindre privilège, autorisation hors du modèle et validation de la sortie. Une section entière lui est consacrée plus bas.
LLM02 · Divulgation d’informations sensibles
Dans un assistant RAG (celui qui cherche dans votre documentation avant de répondre), les fiches de paie se retrouvent dans le même index que la politique de congés, et n’importe qui peut poser la question.
Appliquer les droits de l’utilisateur au moment de la recherche, avant que le texte n’atteigne le modèle, n’indexer que le nécessaire et vérifier quelles données apparaissent dans les réponses et les journaux.
LLM03 · Chaîne d’approvisionnement
Un modèle, des poids, une bibliothèque Python ou un jeu de données tiers arrivent modifiés ou sous une licence qui n’autorise pas votre usage. Les poids sont des fichiers énormes et opaques, alors personne ne regarde dedans.
Sources vérifiées, versions figées, empreintes contrôlées et formats qui n’exécutent pas de code au chargement (safetensors ou GGUF plutôt que pickle).
LLM04 · Empoisonnement des données et du modèle
Quelqu’un glisse des données manipulées dans l’entraînement, l’affinage ou les documents du RAG, et parvient à biaiser les réponses ou à installer une porte dérobée déclenchée par un mot précis.
Savoir d’où vient chaque document, contrôler qui peut ajouter du contenu à l’index et rejouer une série de cas connus après chaque changement.
LLM05 · Mauvaise gestion des sorties
Le texte du modèle est affiché dans une page web, exécuté comme requête SQL ou utilisé comme commande sans contrôle. C’est la bonne vieille injection avec un nouvel intermédiaire : XSS, injection SQL ou exécution de code à distance.
Traiter la sortie du modèle comme n’importe quelle saisie utilisateur : la valider, l’échapper et utiliser des requêtes paramétrées.
LLM06 · Agentivité excessive
Un agent dont les outils ont plus de droits que nécessaire, ou qui enchaîne les actions sans que personne ne les confirme. Une injection passe alors d’une réponse bizarre à un e-mail envoyé, un fichier supprimé ou un paiement effectué.
Moindre privilège pour chaque outil, autorisation vérifiée dans le service qui exécute l’action et confirmation humaine pour tout ce qui est irréversible.
LLM07 · Fuite du prompt système
Faire répéter ses instructions au modèle est facile. Le vrai problème, c’est ce que certaines équipes y mettent : clés d’API, noms de serveurs internes ou règles métier.
Partir du principe que ces instructions finiront publiques, en retirer les secrets et déplacer les règles importantes vers des contrôles qui ne dépendent pas du modèle.
LLM08 · Faiblesses des vecteurs et des embeddings
La base vectorielle du RAG ne sépare pas les données de chaque client, ou laisse n’importe qui insérer des documents, et la recherche renvoie ce qu’elle ne devrait pas, ou ce qu’un attaquant a préparé pour remonter.
Des index séparés ou un filtre par droits sur chaque requête, l’écriture restreinte et la trace des fragments utilisés pour chaque réponse.
LLM09 · Désinformation
Le modèle se trompe avec aplomb, invente des références ou valide des chiffres qui ne tiennent pas, et cela finit dans un rapport ou sur le site sans que personne ne relise.
Des réponses qui citent leur source, un assistant qui s’abstient quand il n’en trouve pas et une relecture humaine pour tout ce qui est publié ou décidé.
LLM10 · Consommation illimitée
Un utilisateur malveillant ou une boucle dans un agent fait exploser la facture ou met le service à terre, et avec assez de requêtes bien choisies on peut copier le comportement du modèle.
Quotas par utilisateur, limites de taille en entrée et en sortie, durée maximale par requête et alertes quand la consommation sort de l’ordinaire.
En décembre 2025, l’OWASP a aussi publié le Top 10 pour les applications agentiques 2026, consacré aux systèmes qui planifient et agissent seuls. Il ne remplace pas cette liste : il la prolonge pour le cas où LLM01 et LLM06 se rencontrent.
correctif qui mette fin à l’injection de prompt.
C’est pour cela que l’OWASP la garde en tête de listeL’injection de prompt en détail
Le premier réflexe de presque toutes les équipes est de filtrer les phrases suspectes, et cela ne suffit pas, car une instruction peut s’écrire de mille façons, dans une autre langue, encodée ou répartie sur plusieurs documents. Les classificateurs spécialisés comme Prompt Guard aident comme couche supplémentaire et arrêtent les tentatives grossières, mais l’approche qui tient consiste à considérer que l’injection aura lieu et à concevoir le système pour qu’elle fasse peu de dégâts ce jour-là.
En pratique, cela se traduit par six choix de conception, et aucun ne compte sur la bonne conduite du modèle :
- Le contenu externe entre marqué comme tel et séparé des instructions lors de la construction de la requête, pour que le modèle et les filtres sachent ce qui relève des données.
- Chaque outil reçoit le plus petit droit qui suffise : un agent qui résume des e-mails n’a pas besoin de pouvoir en envoyer.
- L’autorisation se vérifie hors du modèle, dans le service qui exécute l’action et avec l’identité de l’utilisateur réel, jamais celle de l’agent.
- La sortie est validée par rapport à ce qui est attendu avant d’être utilisée, comme un formulaire.
- Tout ce qui est irréversible (envoyer, supprimer, payer) demande la confirmation d’une personne.
- Tout est journalisé à un endroit que quelqu’un consulte, parce qu’une injection qui réussit ne produit aucune erreur et peut passer inaperçue pendant des semaines.
Et tout cela se teste. Une série d’injections connues, rejouée à chaque changement de modèle, d’instructions ou de documents, fait la différence entre une défense dont on croit qu’elle fonctionne et une défense dont on sait qu’elle fonctionne.
Si le modèle tourne sur vos serveurs
De plus en plus d’entreprises hébergent le modèle sur leur propre infrastructure pour que les données ne sortent pas, et c’est une bonne raison (nous l’expliquons dans quel serveur faut-il pour un LLM en local). Mais un modèle local n’hérite d’aucune protection du simple fait d’être dans votre datacenter : les risques se redistribuent, et cinq des dix changent de place.
| Risque | Avec une API externe | Avec le modèle en local |
|---|---|---|
| LLM02 Informations sensibles | Les données partent chez le fournisseur et vous dépendez de son contrat. | Elles restent chez vous, mais les droits du RAG restent votre affaire. |
| LLM03 Chaîne d’approvisionnement | Le fournisseur choisit et protège les poids. | C’est vous qui les téléchargez : format, origine et empreinte deviennent votre problème. |
| LLM04 Empoisonnement | Vous ne contrôlez pas l’entraînement de base. | Si vous faites de l’affinage, le jeu de données et qui y touche relèvent de votre responsabilité. |
| LLM07 Prompt système | Il part chez le fournisseur à chaque requête. | Il reste en interne, même si le modèle peut toujours le répéter. |
| LLM10 Consommation illimitée | L’abus se paie sur la facture au token. | Pas de facture, mais le GPU sature et le service tombe pour tout le monde. |
La chaîne d’approvisionnement mérite un avertissement précis : les fichiers de poids enregistrés avec pickle, le format classique de PyTorch, peuvent exécuter du code au moment du chargement. Télécharger un modèle depuis un dépôt quelconque et l’ouvrir revient à lancer le programme d’un inconnu. Safetensors et GGUF ne stockent que les nombres, et c’est pourquoi il vaut la peine de les exiger. La consommation suit la même logique : les serveurs d’inférence comme vLLM ou Ollama ont bien des limites (requêtes simultanées, longueur maximale de contexte, file d’attente), mais leurs réglages par défaut visent le débit et non la résistance aux abus, et il faut les ajuster.
L’injection de prompt et l’agentivité excessive, en revanche, ne bougent pas d’un millimètre. Un agent local autorisé à écrire dans la base de données est exactement aussi dangereux qu’un agent dans le cloud.
fichier de poids en pickle suffit pour exécuter du code au chargement du modèle.
Safetensors ou GGUF, toujoursQuoi journaliser pour être prévenu à temps
Une injection qui réussit ne laisse aucune erreur dans les journaux : le modèle fait ce qu’on lui a demandé, l’outil répond que tout va bien et l’utilisateur ne remarque rien. La détection doit donc être construite exprès, en enregistrant pour chaque requête qui l’a faite, quels fragments de documents ont été récupérés (avec leur identifiant), quels outils ont été appelés et avec quels paramètres, quelles validations ont échoué et combien de tokens elle a consommés.
Tout cela part dans le SIEM, le système qui centralise les journaux et les alertes de sécurité (QRadar, Wazuh ou celui que vous utilisez). On peut alors écrire des règles pensées pour une application LLM :
- Un agent appelle un outil d’envoi ou d’écriture juste après avoir lu un document externe.
- Une réponse contient des fragments de documents d’un groupe auquel l’utilisateur n’appartient pas.
- La consommation d’un utilisateur ou d’un agent bondit bien au-dessus de sa moyenne de la semaine passée.
- Le classificateur d’injections ou la validation de sortie rejette des requêtes à répétition depuis le même compte.
Aucun SIEM ne livre ces règles d’origine, puisqu’elles dépendent de la façon dont votre application est construite, mais ce sont elles qui transforment une découverte de test d’intrusion en alerte que l’équipe sécurité voit le jour même de l’attaque.
Par où commencer
Si vous avez une application d’IA en production ou sur le point de l’être, l’ordre que nous proposons commence par la cartographie : quelles données entrent, quels outils elle peut utiliser et où sont les secrets, car sans elle impossible de prioriser quoi que ce soit. Viennent ensuite les droits des outils et des documents (LLM02, LLM06 et LLM08 sont ceux qui causent généralement les frayeurs les plus coûteuses) et les limites de consommation, et enfin les tests et la journalisation que nous venons de décrire.
N’oubliez pas non plus le volet classique : beaucoup d’applications LLM sont exposées comme une API parmi d’autres, et les contrôles du Top 10 OWASP de la sécurité des API s’y appliquent toujours.
Nous travaillons tout cela avec les équipes sécurité et développement dans notre formation Sécurité de l’IA : OWASP pour les LLM et red teaming, en attaquant et en défendant une application volontairement vulnérable. Et si vous avez besoin de concevoir des agents sûrs dès le départ, c’est notre service d’intégration d’agents IA sécurisés.
Questions fréquentes
Qu’est-ce que le Top 10 OWASP pour les LLM ?
C’est la liste des dix risques de sécurité les plus importants dans les applications qui utilisent des modèles de langage, publiée par la fondation OWASP. L’édition en vigueur est celle de 2025 et va de LLM01, l’injection de prompt, à LLM10, la consommation illimitée.
En quoi diffère-t-il du Top 10 OWASP classique ?
Le Top 10 classique couvre les applications web en général. Celui des LLM se concentre sur ce qui change quand un modèle de langage intervient, comme l’injection de prompt, les agents aux droits trop larges, le RAG ou la consommation illimitée, et les deux s’appliquent en même temps.
Peut-on empêcher complètement l’injection de prompt ?
Pas aujourd’hui. On peut en revanche limiter les dégâts avec le moindre privilège, l’autorisation hors du modèle, la validation de la sortie, la confirmation humaine pour les actions irréversibles et la surveillance.
Un modèle en local est-il plus sûr ?
Il évite que les données partent chez un fournisseur externe, mais il confie à votre équipe la chaîne d’approvisionnement des poids et le contrôle de la consommation, et il ne protège ni contre l’injection de prompt ni contre les agents aux droits trop larges.
Qu’est-ce que le Top 10 OWASP pour les applications agentiques ?
C’est une liste complémentaire publiée par l’OWASP en décembre 2025 pour les systèmes qui planifient et exécutent des actions seuls. Elle prolonge le Top 10 pour les LLM du côté des agents sans le remplacer.
Vous avez un assistant ou un agent en service ?
Dites-nous quelles données il lit, quels outils il peut utiliser et avec quels droits, et nous vous dirons par où nous commencerions à le sécuriser. Si vous voulez plutôt que votre équipe sache l’attaquer et le défendre, c’est l’objet de la formation SXIA07.
Formation et services en sécurité de l’IA · sixe.beBlog!
Notre mission
SIXE garantit que vos infrastructures basées sur les technologies IBM®, Red Hat®, Canonical® et SUSE® restent stables, sécurisées et optimisées aussi longtemps que vous en avez besoin.
Chez SIXE, nous nous engageons pour la durabilité. C’est pourquoi nous vous aidons à concevoir, mettre en œuvre et maintenir des solutions technologiques durables et efficaces.
