Les 10 principaux risques OWASP pour les LLM

Le Top 10 de l'OWASP pour les applications utilisant de grands modèles de langage est une liste élaborée par la communauté qui recense les risques de sécurité les plus critiques propres aux systèmes fondés sur des LLM. Elle reprend le célèbre Top 10 de l'OWASP pour le web, tout en traitant des menaces que les listes classiques d'AppSec ne couvrent pas.

Cette liste existe parce que les applications utilisant des LLM introduisent une nouvelle surface d'attaque : un flux de contrôle en langage naturel, des sorties non déterministes, des chaînes d'approvisionnement de modèles et des agents autonomes. Elle fournit aux équipes de sécurité un vocabulaire commun et une liste de contrôle pour la modélisation des menaces.

Les codes ci-dessous utilisent la numérotation LLM01-LLM10 de l'édition 2025.

LLM01 : Injection d’instructions constitue systématiquement le risque numéro un. Un texte contrôlé par l’attaquant prend le pas sur les instructions du développeur, car le modèle ne peut pas distinguer les instructions fiables des données non fiables.

• Directe : l’utilisateur saisit des instructions de remplacement.
• Indirecte : les instructions sont dissimulées dans des pages Internet, des fichiers ou la sortie d’un outil récupérés.

Mesures d’atténuation : appliquez le principe du moindre privilège aux outils, traitez tout le contenu récupéré comme des données, ajoutez des points de contrôle humains pour les actions sensibles et interrompez la voie d’exfiltration des données.

LLM02 : Divulgation d’informations sensibles concerne la révélation, par le modèle, de données qu’il ne devrait pas divulguer : PII, secrets, données d’entraînement propriétaires ou informations d’un autre locataire.

Les fuites se produisent par l’intermédiaire de données d’entraînement mémorisées, d’une injection de contexte trop large ou d’instructions system contenant des identifiants.

• Nettoyez et minimisez les données placées dans le contexte.
• Ne placez jamais de secrets actifs dans les instructions ; utilisez hors bande des jetons à portée limitée et à courte durée de vie.
• Appliquez un filtrage des sorties et des contrôles de prévention des pertes de données avant de renvoyer les réponses.

LLM03 : Chaîne d’approvisionnement concerne les risques provenant de modèles, jeux de données, modules d’extension et bibliothèques de tiers. Un modèle de base empoisonné, un ajustement fin contenant une porte dérobée provenant d’une plateforme de modèles ou une dépendance Python malveillante peut compromettre l’application entière.

• Vérifiez l’origine des modèles et leurs sommes de contrôle.
• Figez les versions et vérifiez les licences.
• Analysez les fichiers de modèle sérialisés (pickle peut exécuter du code au chargement) et préférez des formats sûrs comme safetensors.

LLM04 : Empoisonnement des données et du modèle vise la chaîne de traitement de l’entraînement ou de l’ajustement fin. Un attaquant capable d’influencer les données d’entraînement peut implanter des portes dérobées (déclencheurs cachés), biaiser les sorties ou dégrader la qualité.

Les chaînes de traitement RAG qui ingèrent des documents soumis par les utilisateurs constituent une surface d’empoisonnement active, même après le déploiement.

• Vérifiez soigneusement les sources de données d’entraînement et signez-les.
• Utilisez la détection d’anomalies sur les jeux de données.
• Isolez et examinez le contenu fourni par les utilisateurs avant son indexation.

LLM05 : Mauvaise gestion des sorties se produit lorsque les composants en aval font confiance à la sortie du modèle sans la valider. Comme la sortie peut être influencée par un attaquant au moyen d’une injection, la transmettre sans validation à un interpréteur de commandes, à une requête SQL, à un navigateur ou à une évaluation de code constitue une voie directe vers XSS, SSRF ou RCE.

Règle : traitez la sortie du LLM exactement comme une entrée utilisateur non fiable. Encodez-la, validez-la et isolez-la avant qu’elle n’atteigne un interpréteur.

LLM06 : Autonomie excessive désigne les dommages causés lorsque le modèle dispose de trop de fonctionnalités, de trop d’autorisations ou d’une autonomie excessive. Lorsque le modèle peut appeler des outils, une injection devient une action, et non plus seulement du texte.

• Fonctionnalités excessives : des outils dont l’application n’a pas réellement besoin.
• Autorisations excessives : un outil doté de fonctions d’écriture et de suppression alors que la lecture suffit.
• Autonomie excessive : des actions à fort impact sans approbation humaine.

Appliquez le principe du moindre privilège à chaque outil et exigez une confirmation pour les opérations irréversibles.

LLM07 : Fuite des instructions system rappelle que les instructions system ne constituent pas un espace de stockage sécurisé pour les secrets. Les attaquants peuvent souvent les extraire et elles contiennent parfois des identifiants, une logique métier cachée ou des règles de filtrage qui facilitent d’autres attaques.

• Supposez que les instructions system peuvent être récupérées ; n’y intégrez jamais de secrets ni de clés.
• Imposez l’autorisation dans votre backend, plutôt que d’espérer qu’une règle des instructions soit respectée.
• Considérez tout mécanisme de sécurité comme défaillant s’il se trouve uniquement dans le texte des instructions.

Les entrées restantes :

• LLM08 Faiblesses des vecteurs et des représentations vectorielles : risques liés aux représentations vectorielles RAG, notamment les fuites entre locataires, l’inversion des représentations vectorielles et l’indexation de documents empoisonnés. Appliquez le contrôle d’accès au moment de la récupération.
• LLM09 Désinformation : hallucinations formulées avec assurance et confiance excessive. Ajoutez un ancrage dans les sources, des citations et une vérification humaine pour les sorties à forts enjeux.
• LLM10 Consommation sans limites : déni de portefeuille et attaques par déni de service dus à des requêtes coûteuses ou qui s’emballent. Appliquez des limites de débit, des budgets de jetons, des délais d’expiration et des alertes de coût.

Le Top 10 est particulièrement utile comme liste de contrôle structurée lors de la revue de conception :

• Associez chaque composant (entrée, récupération, outils, sortie) aux risques LLM pertinents.
• Pour chaque risque, définissez un mécanisme concret et un responsable.
• Rédigez des cas d’abus et transformez-les en tests automatisés.

Associez-le aux cadres existants, comme la liste standard des 10 principaux risques d’OWASP, MITRE ATLAS pour les tactiques propres à l’apprentissage automatique et le cadre de gestion des risques liés à l’IA de NIST pour la gouvernance.

Aucun mécanisme unique ne couvre ces risques. Superposez-les :

• Couche d’entrée : validation, classification, limites de débit.
• Couche du modèle : outils soumis au principe du moindre privilège, contexte limité, modèles de protection.
• Couche de sortie : validation, encodage, DLP, approbation humaine.
• Couche de plateforme : journalisation, surveillance, vérification de la chaîne d’approvisionnement, contrôles des coûts.

Supposez que chaque couche puisse échouer et concevez le système de sorte qu’une seule défaillance ne devienne pas une compromission.

Les 10 principaux risques LLM d’OWASP en bref :

• LLM01 Injection d’instructions, LLM02 Divulgation d’informations sensibles, LLM03 Chaîne d’approvisionnement, LLM04 Empoisonnement des données et du modèle, LLM05 Mauvaise gestion des sorties.
• LLM06 Autonomie excessive, LLM07 Fuite des instructions system, LLM08 Faiblesses des vecteurs et des représentations vectorielles, LLM09 Désinformation, LLM10 Consommation sans limites.
• Traitez la sortie du modèle et les instructions system comme non fiables et non secrètes.
• Utilisez cette liste comme liste de contrôle pour la modélisation des menaces, associez-la à MITRE ATLAS et NIST IA RMF, et appliquez une défense en profondeur aux couches d’entrée, du modèle, de sortie et de plateforme.