Sécurité & gouvernance · Sécurité IA
OWASP Top 10 : les principaux risques des applications LLM
L'OWASP Top 10 2025 montre que la sécurité d'une application LLM dépasse le modèle. Injection, données sensibles, supply chain, outils et coûts doivent être contrôlés sur toute l'architecture.
La sécurité d'une application LLM ne se résume pas à empêcher un utilisateur de contourner un prompt système. Le modèle reçoit des données, récupère des documents, appelle parfois des outils et transmet ses sorties à d'autres composants. Chaque frontière peut transformer une réponse plausible en fuite de données, action non autorisée ou incident opérationnel.
L'OWASP Top 10 for LLM Applications 2025 fournit une taxonomie utile de ces risques. Il ne s'agit ni d'une certification ni d'une liste de contrôle suffisante à elle seule. C'est un point de départ pour modéliser les menaces, sélectionner des contrôles et tester l'application complète.
En bref
Les contrôles les plus importants sont transverses :
- traiter prompts, documents récupérés et sorties comme des données non fiables ;
- isoler les données par utilisateur et appliquer le moindre privilège ;
- valider en code chaque sortie avant une action ou une interprétation ;
- limiter les outils, paramètres, volumes et budgets accessibles au modèle ;
- gouverner modèles, jeux de données, embeddings et composants tiers ;
- journaliser les décisions de sécurité sans exposer de données sensibles ;
- tester régulièrement les chemins d'attaque, y compris dans le RAG et les agents.
Les risques OWASP traversent toute la chaîne de l'application. Les contrôles doivent couvrir les frontières entre composants.
Les dix risques OWASP 2025
La version 2025, également appelée version 2.0, réorganise la liste précédente. Elle ajoute notamment la fuite du prompt système et les faiblesses liées aux vecteurs et embeddings, tandis que la consommation non bornée élargit l'ancien risque de déni de service du modèle.
| Référence | Risque | Scénario typique | Contrôle prioritaire |
|---|---|---|---|
| LLM01 | Injection de prompt | Une instruction dans un message ou un document détourne le comportement | Séparer données et instructions, limiter les effets possibles, tester les injections |
| LLM02 | Divulgation d'informations sensibles | Le système révèle une donnée personnelle, un secret ou un contexte interne | Minimisation, contrôle d'accès, filtrage et règles de rétention |
| LLM03 | Supply chain | Un modèle, jeu de données, adaptateur ou composant compromis entre dans le système | Inventaire, provenance, vérification des artefacts et fournisseurs |
| LLM04 | Empoisonnement des données et du modèle | Des données modifiées introduisent une porte dérobée, un biais ou un comportement dangereux | Gouvernance des sources, validation, versionnement et tests de régression |
| LLM05 | Traitement incorrect des sorties | Une sortie LLM non validée devient une requête, du code ou du contenu exécuté | Validation contextuelle, encodage et séparation des interpréteurs |
| LLM06 | Agence excessive | Le modèle possède trop d'outils, de permissions ou d'autonomie | Moindre privilège, approbation, limites d'action et réversibilité |
| LLM07 | Fuite du prompt système | Des instructions internes sont exposées ou utilisées comme secret | Ne placer aucun secret dans le prompt, renforcer les contrôles hors modèle |
| LLM08 | Faiblesses des vecteurs et embeddings | Un RAG récupère des contenus non autorisés ou malveillants | Isolation, autorisation avant récupération, validation et traçabilité des sources |
| LLM09 | Désinformation | Une réponse fausse ou non fondée influence une décision | Ancrage dans les sources, incertitude, vérification et supervision humaine |
| LLM10 | Consommation non bornée | Une entrée ou boucle déclenche un coût, un calcul ou un volume excessif | Quotas, délais, limites de profondeur, budgets et arrêt automatique |
LLM01 : injection de prompt
Une injection de prompt tente de modifier le comportement du modèle avec une entrée conçue à cet effet. Elle peut être directe, lorsque l'utilisateur écrit l'instruction, ou indirecte, lorsqu'elle est dissimulée dans un document, une page web, un courriel ou une donnée récupérée par le système.
Le problème fondamental est que le modèle traite instructions et données dans un même canal sémantique. Un filtre de mots ou un prompt demandant d'ignorer les attaques ne suffit pas.
Les mesures les plus robustes réduisent l'impact possible : outils explicitement autorisés, paramètres validés, permissions minimales, séparation des données, validation humaine pour les actions sensibles et tests adversariaux continus.
LLM02 : divulgation d'informations sensibles
Une donnée peut fuir par le prompt, le contexte RAG, les journaux, la mémoire de conversation, une sortie ou le fournisseur du modèle. L'application doit donc connaître la classification des données avant l'appel au modèle et décider lesquelles sont nécessaires.
Appliquez la minimisation, le contrôle d'accès par ressource, le chiffrement, les règles de rétention et la prévention des secrets. Vérifiez aussi les engagements contractuels du fournisseur et la destination des traces techniques.
Un masquage automatique ne doit pas être considéré comme parfait. Les identifiants indirects, les pièces jointes et les données structurées exigent des tests adaptés.
LLM03 et LLM04 : supply chain et empoisonnement
Une application LLM dépend souvent d'un modèle, de bibliothèques, d'une base vectorielle, de datasets, d'adaptateurs, de plugins, de modèles d'embedding et d'API. Une compromission ou une provenance incertaine peut modifier le comportement sans changement visible du code applicatif.
Maintenez un inventaire des composants et versions, vérifiez l'origine et l'intégrité des artefacts, contrôlez les licences et évaluez les fournisseurs. Pour les données d'entraînement, de fine-tuning ou de RAG, documentez les sources, les droits de modification et les validations.
Les tests de régression doivent couvrir les comportements critiques après chaque changement de modèle, dataset ou composant.
LLM05 : traitement incorrect des sorties
Une sortie de modèle est une donnée non fiable. Si elle est injectée directement dans une page HTML, une requête SQL, une commande, un modèle de courrier ou un interpréteur, elle peut déclencher une vulnérabilité classique en aval.
Validez la sortie selon sa destination. Un schéma JSON vérifie une structure, mais pas l'autorisation ni le sens métier. Utilisez des listes d'actions permises, encodez pour le contexte d'affichage et maintenez une frontière claire entre génération et exécution.
LLM06 : agence excessive
Un agent devient dangereux lorsqu'il cumule trop de capacités, de permissions et d'autonomie. Le modèle peut choisir un mauvais outil, produire des paramètres incorrects ou être manipulé par une entrée indirecte.
Donnez à chaque outil une identité dédiée et des droits minimaux. Limitez les ressources, montants, destinataires et fréquences. Exigez une approbation humaine pour les actions irréversibles ou sensibles et fournissez un aperçu avant exécution. Concevez aussi la compensation ou l'annulation lorsque c'est possible.
Le modèle ne doit jamais décider seul s'il est autorisé à agir. Cette décision appartient à un composant déterministe contrôlé par la politique de l'entreprise.
LLM07 : fuite du prompt système
Le prompt système peut être révélé en totalité ou en partie. Il faut donc partir du principe qu'il n'est pas secret. Une clé API, un mot de passe, une règle d'autorisation confidentielle ou une information sensible ne doit jamais y être stocké.
La protection réelle repose sur les contrôles d'identité, d'accès, de validation et d'exécution situés hors du modèle. La fuite d'une instruction interne reste un signal à surveiller, mais elle ne doit pas suffire à compromettre le système.
LLM08 : faiblesses des vecteurs et embeddings
Un RAG ajoute une surface d'attaque. Des documents malveillants peuvent influencer la réponse, des espaces partagés peuvent créer une fuite entre utilisateurs et des métadonnées incorrectes peuvent contourner les règles de récupération.
Appliquez les autorisations avant la recherche, puis à nouveau avant d'utiliser le document. Isolez les collections lorsque le risque l'exige. Conservez la provenance de chaque extrait, filtrez les types de contenus acceptés et testez les injections indirectes dans les documents.
LLM09 : désinformation
Une réponse grammaticalement correcte peut être fausse, obsolète ou inventée. Le risque devient critique lorsqu'elle est présentée comme certaine ou utilisée automatiquement dans une décision.
Ancrez les réponses dans des sources autorisées, exposez les références, mesurez la fidélité et prévoyez une abstention lorsque l'information manque. Les décisions à fort impact exigent une vérification humaine ou un contrôle déterministe.
L'évaluation doit distinguer exactitude, complétude et fidélité aux sources. Une réponse correcte par hasard ne prouve pas que le système s'est appuyé sur la bonne information.
LLM10 : consommation non bornée
Les longues entrées, sorties répétées, appels d'outils, recherches en boucle et tentatives parallèles peuvent provoquer un déni de service ou une facture disproportionnée. Les agents amplifient ce risque lorsqu'ils créent eux-mêmes les étapes suivantes.
Fixez des limites de taille, de durée, de débit, de récursion, d'appels et de budget. Détectez les boucles, imposez une date d'expiration aux tâches et fournissez un mécanisme d'arrêt. Surveillez le coût par utilisateur et par processus, pas seulement le total mensuel.
Une architecture de contrôle en cinq couches
| Couche | Contrôles essentiels |
|---|---|
| Entrée | Authentification, validation, classification des données, limites de taille |
| Contexte et RAG | Autorisation par document, isolation, provenance, filtrage des contenus |
| Modèle | Configuration versionnée, politiques de refus, tests de robustesse |
| Outils et sortie | Schémas, validation métier, moindre privilège, approbation avant action |
| Exploitation | Journaux, métriques, quotas, alertes, réponse aux incidents, tests de régression |
Chaque couche doit échouer de façon sûre. Si la récupération ne peut pas vérifier une autorisation, elle ne doit pas renvoyer le document. Si un outil ne peut pas valider un paramètre, il ne doit pas exécuter l'action.
Comment utiliser la liste dans un projet
- Dessinez le flux complet des données et des actions.
- Associez chaque risque OWASP aux composants concernés.
- Décrivez un scénario d'abus concret et son impact métier.
- Sélectionnez des contrôles préventifs, détectifs et correctifs.
- Transformez les scénarios en tests reproductibles.
- Nommez un propriétaire et définissez les preuves attendues.
- Réexécutez les tests après chaque changement important.
Ne cherchez pas à cocher les dix lignes de manière uniforme. Priorisez selon les données, les capacités du système et les conséquences d'un échec. Un chatbot sans outils et un agent autorisé à modifier un ERP n'ont pas le même profil de menace.
La sécurité est une propriété du système
Le principal enseignement de l'OWASP Top 10 est architectural. Un LLM ne peut pas assurer seul la confidentialité, l'autorisation, la validation des sorties et le contrôle des actions. Ces propriétés doivent être imposées par des composants déterministes, des permissions et des processus humains.
Une application LLM sûre limite ce que le modèle peut voir, décider et déclencher. Elle observe ensuite ce qui se produit réellement et réévalue ses contrôles lorsque le modèle, les données ou les outils changent.
Sources officielles
- OWASP Top 10 for LLM Applications 2025, publication officielle et guide complet.
- OWASP LLM01:2025 Prompt Injection, pages officielles donnant accès aux dix catégories et aux mesures proposées.
- NIST AI 600-1: Generative AI Profile, cadre transversal pour gouverner, cartographier, mesurer et gérer les risques de l'IA générative.
Sources vérifiées le 6 août 2026.
