OWASP Top 10 pour les applications LLM

Définition

L'OWASP Top 10 pour les applications LLM est une liste gérée par la communauté répertoriant les classes de vulnérabilités les plus critiques dans les applications basées sur de grands modèles de langage. Elle est publiée par l'OWASP GenAI Security Project et révisée périodiquement au fil de l'évolution de l'écosystème.

Portée

Toute application basée sur un grand modèle de langage — interfaces de chat, systèmes de recherche d'informations (retrieval), agents et outils qu'ils appellent. Elle est volontaire, non certifiable et délibérément descriptive : elle classifie les risques, mais ne prescrit pas de contrôles et ne confère pas de conformité.

Exigences clés

• L'injection de requêtes (prompt injection) figure en tête de liste depuis la première édition et reste la classe pour laquelle il n'existe pas de solution miracle — seul un confinement de sécurité multicouche est possible.
• L'édition 2025 couvre l'injection de requêtes, la divulgation d'informations sensibles, la chaîne d'approvisionnement, l'empoisonnement des données et des modèles, la mauvaise gestion des sorties, l'excès d'autonomie, la fuite de requêtes système, les faiblesses des vecteurs et des plongements (embeddings), la désinformation et la consommation illimitée. La liste étant révisée périodiquement, veuillez consulter l'édition en vigueur plutôt que de vous fier à une version en cache.
• Plusieurs entrées ont un effet spécifique aux agents : l'excès d'autonomie et la mauvaise gestion des sorties ne deviennent critiques que lorsque le modèle est en mesure d'agir.
• Il s'agit d'une taxonomie, pas d'un ensemble de contrôles. Associer une anomalie à LLM06 indique la nature du problème, mais pas ce qu'il faut construire.
• C'est la lingua franca du domaine : les revues de sécurité, les questionnaires des fournisseurs et les rapports de bogues y font tous référence, ce qui explique en grande partie pourquoi il est utile de la connaître par numéro.
• Couvrir la liste ne constitue pas une posture de sécurité. Chaque entrée nécessite un contrôle dans votre architecture, et une entrée sans contrôle représente un risque accepté, que cela ait été formalisé par écrit ou non.

Contrôles

Projeter la liste sur votre propre architecture

Confrontez chaque entrée à vos entrées, outils, bases de données et sorties réels. L'exercice a plus de valeur que la liste elle-même, car il met en évidence les entrées non applicables ainsi que les surfaces d'attaque non mentionnées par la liste.

Attribuer un responsable et un contrôle par entrée

Chaque classe applicable nécessite un composant désigné pour la limiter et une personne pour maintenir ce composant. Une entrée non associée à un contrôle est une faille dotée d'un numéro de référence.

Traiter l'injection de requêtes comme du confinement, pas de la prévention

LLM01 ne dispose d'aucun correctif fiable au niveau du modèle. Les contrôles essentiels sont l'outillage de moindre privilège, la restriction des flux de sortie, la gestion des sorties et les barrières d'approbation pour les actions à fort impact.

Contraindre explicitement l'autonomie

Pour LLM06, définissez par écrit ce que l'agent est autorisé à faire, avec quels identifiants et sur quelles cibles — et appliquez ces règles en aval du modèle plutôt que dans la requête (prompt).

Traiter les sorties du modèle comme des entrées non approuvées

Pour LLM05, tout ce que le modèle génère et qui atteint un moteur de rendu, un interpréteur de commandes (shell), une requête ou un autre système nécessite le même encodage et la même validation que vous appliqueriez à une entrée provenant d'un tiers inconnu.

Limiter la consommation

Pour LLM10, les limites de débit, les quotas et les délais d'expiration transforment une attaque sur la disponibilité et les coûts en un refus consigné dans les journaux. C'est l'entrée que les équipes ignorent le plus souvent, car elle ne ressemble pas à un problème de sécurité avant la réception de la facture.

Relancer la projection lorsque la liste ou le système change

La liste est révisée et votre catalogue d'outils s'enrichit. Une projection réalisée une seule fois devient un document décrivant un système qui n'existe plus.

Liste de contrôle

• 01Lisez l'édition en vigueur plutôt qu'un résumé — y compris celui-ci.
• 02Produisez un tableau de correspondance : entrée → s'applique ? → contrôle → responsable.
• 03Pour chaque entrée applicable sans contrôle, enregistrez-la comme un risque accepté avec un motif et une détection compensatoire.
• 04Écrivez un test pour chaque contrôle et assurez-vous que le test échoue avant de lui faire confiance.
• 05Vérifiez les entrées qui ne posent problème qu'avec des outils : excès d'autonomie, mauvaise gestion des sorties, chaîne d'approvisionnement.
• 06Confirmez que les limites de débit et les quotas existent et renvoient les signaux appropriés aux clients bien intentionnés.
• 07Relancez la projection chaque fois qu'un outil, une source de données ou un niveau d'autonomie change.
• 08Utilisez la numérotation de la liste dans les rapports d'anomalies afin que les réviseurs et les fournisseurs discutent de la même classe.

Pièges courants

• Traiter la liste comme un objectif de conformité : couvrir dix rubriques alors que l'architecture réelle reste non examinée.
• Supposer que le travail de sécurité d'un fournisseur de modèles couvre LLM01. Cela réduit les tentatives, mais les conséquences restent entièrement de votre responsabilité.
• Effectuer la projection sur une édition en cache. La liste étant révisée, une ancienne projection cesse discrètement de couvrir les classes actuelles.
• Ignorer LLM10 parce que la consommation illimitée ressemble à un problème d'exploitation plutôt qu'à un problème de sécurité.
• Confondre le fait de nommer une classe avec le fait de la contrôler. Un tableau de correspondance bien ordonné sans mise en application constitue une documentation du risque, non sa réduction.

Exemples

• Un agent qui résume les e-mails des clients correspond à LLM01 (le corps de l'e-mail est une entrée d'instruction non approuvée), LLM02 (le résumé peut répéter des données que le demandeur ne devrait pas voir) et LLM06 (l'outil CRM transforme un détournement en action) — trois entrées pour une seule fonctionnalité, chacune nécessitant un contrôle différent.
• Un système RAG sur un wiki interne correspond à LLM01 via une injection indirecte provenant de n'importe quel éditeur de page, à LLM04 si l'index peut être empoisonné, et à LLM08 pour une recherche qui renvoie des documents en dehors des autorisations du demandeur.
• Un point de terminaison MCP public correspond le plus nettement à LLM10 : données publiques en lecture seule, de sorte que la limite de consommation — des limites de débit avec des en-têtes corrects — est l'entrée qui effectue le véritable travail.

FAQ

Peut-on être conforme à l'OWASP LLM Top 10 ?

Non. Il s'agit d'un document de sensibilisation et de classification, pas d'une norme certifiable. Il s'associe naturellement à un système de gestion tel qu'ISO 42001 ou à un cadre tel que le NIST AI RMF, où résident réellement les obligations de gouvernance.

Quelles entrées changent le plus lorsque vous ajoutez des outils à un modèle ?

L'excès d'autonomie et la mauvaise gestion des sorties. Sans outils, ils produisent une réponse erronée ; avec des outils, ils produisent une action, et la gravité passe d'une simple gêne à un incident.

Quel est son lien avec MITRE ATLAS ?

Ils répondent à des questions différentes. L'OWASP nomme les classes de vulnérabilités de votre application ; ATLAS catalogue les tactiques et techniques qu'un adversaire utilise contre les systèmes d'IA. L'un est une liste de contrôle pour votre conception, l'autre est une carte des techniques de l'attaquant.

Références

• OWASP — Top 10 for LLM Applications
• OWASP — LLM01: Prompt Injection
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST — AI Risk Management Framework (AI RMF 1.0)

Gouvernance connexe