OWASP Top 10 2025 : chaque risque expliqué avec exemples

Qu'est-ce que l'OWASP Top 10 ?

Qu'est-ce que l'OWASP Top 10 ? L'OWASP Top 10 est un document de sensibilisation de référence qui classe les dix risques de sécurité les plus critiques pour les applications web. Il est publié par l'Open Worldwide Application Security Project, une organisation à but non lucratif qui produit des ressources de sécurité gratuites, et il est reconstruit environ tous les trois à quatre ans à partir de données fournies sur des applications réelles.

Le mot important est risques, pas vulnérabilités. Chaque entrée est une catégorie, pas un seul bug. « Injection » couvre l'injection SQL, le cross-site scripting, l'injection de commandes, et plus encore, toutes regroupées parce qu'elles partagent une cause racine : une entrée non fiable qui atteint un interpréteur. C'est ce regroupement qui rend la liste utile. Vous ne mémorisez pas dix mille bugs, vous comprenez dix schémas et reconnaissez leurs variations.

L'OWASP construit le classement à partir de deux sources. La plupart des catégories proviennent de données : des éditeurs de sécurité et des cabinets de test soumettent des résultats mappés à des identifiants Common Weakness Enumeration (CWE) sur des centaines de milliers d'applications, et l'OWASP calcule à quelle fréquence chaque classe de faiblesse apparaît et quel impact elle porte. Un plus petit nombre de catégories provient d'une enquête sectorielle, qui capte les risques émergents que les scanners automatisés manquent parce que les outils ne savent pas encore bien les détecter. La Conception non sécurisée est entrée dans la liste par cette voie.

La liste compte parce qu'elle est devenue le langage commun de la sécurité applicative. Les cadres de conformité y font référence, les descriptions de poste l'attendent, et les triageurs de bug bounty catégorisent leurs rapports avec elle. Connaître l'OWASP Top 10 est le socle de base pour quiconque teste ou défend des applications web, c'est pourquoi elle ancre tout cours d'attaques web sérieux et apparaît dans presque tous les programmes de certification offensive.

La liste OWASP Top 10 2025

Voici le classement complet 2025, tel que publié dans l'OWASP Top 10 2025 officiel. Chaque risque ci-dessous inclut ce qu'il est, un exemple concret, et un lab où vous pouvez l'exploiter vous-même. Parcourez-les dans l'ordre la première fois ; le classement suit à peu près la fréquence à laquelle vous rencontrerez chacun d'eux sur le terrain.

A01:2025 - Contrôle d'accès défaillant

Le contrôle d'accès défaillant survient lorsqu'une application ne parvient pas à faire respecter ce qu'un utilisateur est autorisé à faire, lui permettant de lire ou de modifier des données qui devraient être interdites. C'est le risque web numéro un depuis 2021 et il l'est resté en 2025, absorbant désormais le Server-Side Request Forgery comme sous-cas.

L'exemple classique est une référence directe non sécurisée à un objet (IDOR). Vous consultez votre propre facture à l'adresse /invoice?id=1043, vous changez le numéro en 1044, et l'application vous remet la facture de quelqu'un d'autre parce qu'elle a vérifié que vous étiez connecté mais jamais que l'enregistrement vous appartenait. La même défaillance couvre la navigation forcée vers des pages d'administration, la falsification d'un claim de rôle dans un JWT, et l'accès à des services internes via une requête que le serveur effectue en votre nom (le cas SSRF désormais intégré ici).

Entraînez-vous dessus dans le lab IDOR Explorer, faites une élévation de privilèges vers un panneau d'administration dans Admin Portal Breach, ou exploitez la variante server-side request forgery dans SSRF Validator.

A02:2025 - Mauvaise configuration de sécurité

La mauvaise configuration de sécurité est un système laissé dans un état non sécurisé à cause de valeurs par défaut, d'oublis ou de fonctionnalités inutiles plutôt que d'un bug de code. Elle est passée de la cinquième place en 2021 à la deuxième en 2025, ce qui reflète à quel point les compromissions modernes viennent d'une installation bâclée plutôt que d'une exploitation ingénieuse.

Pensez à des identifiants par défaut laissés sur une console d'administration, un bucket de stockage cloud réglé en public, le listing de répertoire activé, des pages d'erreur verbeuses qui laissent fuir des traces de pile, ou un dossier .git exposé qui livre à un attaquant tout votre arbre de sources. Aucun de ces cas ne nécessite un zero-day. Ils nécessitent que quelqu'un remarque que la porte n'a jamais été verrouillée.

Le lab Git Exposed vous permet de reconstruire une application à partir d'un dépôt déployé négligemment, et le cours Bases de la sécurité web couvre les erreurs de configuration qui causent cette classe.

A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle

Les défaillances de la chaîne d'approvisionnement logicielle couvrent les risques introduits par les composants, les dépendances et les pipelines de build sur lesquels votre application repose plutôt que par le code écrit par votre équipe. En 2025, l'OWASP a élargi l'ancienne catégorie « Composants vulnérables et obsolètes » en une chaîne d'approvisionnement complète, parce que la façon dont les logiciels sont construits a changé plus vite que ne le permettait l'ancien nom.

Une dépendance avec une CVE connue que vous n'avez jamais corrigée est le cas le plus simple. Log4Shell était une seule faille de bibliothèque qui a exposé des millions d'applications du jour au lendemain. Pire encore sont les compromissions actives : un compte de mainteneur se fait hameçonner et une version malveillante d'un paquet npm populaire est livrée à tous ceux qui lancent une mise à jour. Votre code peut être parfait et vous vous faites quand même compromettre par un paquet que vous n'avez jamais lu.

Défendre cette classe signifie connaître vos dépendances, épingler les versions, vérifier les signatures et scanner votre build. Le cours Sécurité des conteneurs et de Kubernetes couvre l'intégrité de la chaîne d'approvisionnement pour les builds conteneurisés, où ce risque se concentre.

A04:2025 - Défaillances cryptographiques

Les défaillances cryptographiques surviennent lorsque des données sensibles ne sont pas protégées correctement, que ce soit à cause d'algorithmes faibles, d'un chiffrement absent ou d'une mauvaise gestion des clés. Elles étaient en deuxième position en 2021 et sont passées en quatrième en 2025, non pas parce qu'elles sont devenues moins graves mais parce que la mauvaise configuration et la chaîne d'approvisionnement sont passées au-dessus.

L'exemple de tous les jours est le stockage des mots de passe. Une application qui stocke les mots de passe sous forme de hachages MD5 non salés les a de fait stockés en clair, car un hachage MD5 divulgué d'un mot de passe courant se casse en quelques millisecondes. D'autres cas incluent la transmission de données via du HTTP en clair, le codage en dur d'une clé de chiffrement dans le source, ou l'utilisation d'un mode de chiffrement cassé qui laisse fuir des motifs dans le texte chiffré.

Pour ressentir pourquoi le hachage faible échoue, cassez de vrais hachages dans le lab Crack SHA1 Hash, puis lisez notre tutoriel de cassage de hachages et notre explication sur pourquoi on ne peut pas simplement inverser un hachage MD5. Le cours Cassage de mots de passe montre le côté offensif de bout en bout.

A05:2025 - Injection

L'injection survient lorsqu'une entrée non fiable est interprétée comme une commande ou une requête, permettant à un attaquant de changer ce que l'application fait. Elle inclut l'injection SQL, le cross-site scripting, l'injection de commandes, l'injection LDAP et l'injection NoSQL, toutes partageant une cause racine : des données qui passent dans un endroit destiné au code. L'injection est descendue de la troisième place en 2021 à la cinquième en 2025 à mesure que les frameworks ont rendu les cas courants plus difficiles, mais elle n'a pas disparu.

Le cas d'école est l'injection SQL. Un formulaire de connexion construit une requête en collant votre entrée directement dans une chaîne, donc saisir ' OR '1'='1 comme mot de passe transforme la requête en une requête toujours vraie et vous connecte en tant que premier utilisateur de la table. Le cross-site scripting est la même idée visant le navigateur : un champ de commentaire qui renvoie <script> sans échappement exécute votre JavaScript dans la session de chaque visiteur.

Exploitez l'injection SQL de manière pratique dans Query Quake, l'un des labs les plus populaires sur HackerDNA, et le cross-site scripting dans le XSS Playground. Notre tutoriel d'injection SQL et notre analyse de XSS contre CSRF approfondissent les deux que vous rencontrerez le plus.

A06:2025 - Conception non sécurisée

La conception non sécurisée est une faille dans la logique voulue d'une application plutôt qu'une erreur dans sa mise en œuvre. Vous ne pouvez pas la corriger avec un en-tête de sécurité parce que le problème est le plan lui-même. Elle était en quatrième position en 2021 et se situe en sixième en 2025, toujours un rappel que tous les bugs ne sont pas des fautes de frappe.

Un flux de réinitialisation de mot de passe qui envoie un code à six chiffres mais ne limite jamais le nombre de tentatives que vous obtenez est conçu de manière non sécurisée : le code est correct, l'absence de limitation de débit est le trou. Les failles de logique métier vivent ici aussi, comme un paiement qui vous laisse appliquer mille fois la même réduction à usage unique, ou un virement qui accepte un montant négatif et déplace l'argent dans le mauvais sens.

Ceux-ci nécessitent un testeur qui réfléchit à la façon dont la fonctionnalité peut être détournée, pas seulement à savoir si elle fonctionne. Le lab API Logic Flaw est construit exactement autour de ce genre de faiblesse au niveau de la conception.

A07:2025 - Défaillances d'authentification

Les défaillances d'authentification sont des faiblesses dans la manière dont une application confirme qui est un utilisateur et le maintient connecté. L'OWASP a raccourci le nom de 2021 « Défaillances d'identification et d'authentification » en simplement « Défaillances d'authentification » en 2025, mais le fond est le même. Elles sont restées en septième position.

Les défaillances se regroupent en quelques endroits : autoriser des mots de passe faibles ou compromis, ne pas se défendre contre le credential stuffing, exposer des jetons de session qui n'expirent jamais, et mal gérer les JSON Web Tokens. Une bibliothèque JWT qui accepte l'en-tête alg: none fera confiance à un jeton qu'un attaquant a forgé sans aucune signature, remettant tout compte qu'il nomme.

Cassez une connexion dans Hack the Login, parcourez un contournement d'authentification dans Auth Bypass, et forgez des jetons dans JWT Algorithm Confusion. Le cours JWT Hacking couvre les attaques de jetons en profondeur.

A08:2025 - Défaillances d'intégrité des logiciels ou des données

Les défaillances d'intégrité des logiciels ou des données surviennent lorsqu'une application fait confiance à du code ou à des données sans vérifier qu'ils n'ont pas été altérés. Le nom de 2025 remplace « et » par « ou » mais garde le sens de 2021. Elles sont restées en huitième position.

La désérialisation non sécurisée est l'exemple le plus tranchant. Une application qui dépickle un objet Python ou désérialise un objet PHP à partir d'une entrée utilisateur peut être trompée pour exécuter du code choisi par l'attaquant, transformant un champ de données en exécution de code à distance. La catégorie couvre aussi les mécanismes de mise à jour automatique qui récupèrent du code via un canal non vérifié et les pipelines CI/CD qui déploient des artefacts sans vérifier de signature.

Mettez la main à la pâte avec le lab Pickle Deserializer, où un objet sérialisé de confiance devient un shell, et le lab Type Juggling Bypass pour une faille d'intégrité connexe dans les comparaisons laxistes.

A09:2025 - Défaillances de journalisation et d'alerte de sécurité

Les défaillances de journalisation et d'alerte de sécurité signifient qu'une application n'enregistre pas les événements pertinents pour la sécurité ou ne déclenche pas d'alarme quand quelque chose ne va pas, si bien que les attaques passent inaperçues. L'OWASP a renommé la « Surveillance » de 2021 en « Alerte » en 2025 pour souligner que collecter des journaux ne sert à rien si personne ne les regarde. Elles sont restées en neuvième position.

Le dommage ici se mesure en temps. Un site qui ne journalise jamais les connexions échouées ne peut pas savoir que quelqu'un a mené une attaque de credential stuffing pendant trois semaines. Le temps de présence moyen du secteur, l'écart entre une compromission et sa détection, se mesure encore en semaines ou en mois, et l'absence de journaux en est une grande partie de la raison. C'est la seule catégorie de la liste qui vous nuit plus en tant que défenseur qu'elle ne vous aide en tant qu'attaquant, et c'est pourquoi les équipes bleues existent.

Le côté défenseur de cela est là où vit l'analyse de journaux. Entraînez-vous à extraire des attaques des journaux dans le lab Log Hunter, et voyez le flux de détection complet dans le cours Investigation numérique et réponse aux incidents.

A10:2025 - Mauvaise gestion des conditions exceptionnelles

La mauvaise gestion des conditions exceptionnelles est une toute nouvelle catégorie 2025 qui couvre ce qui se passe lorsqu'une application rencontre une erreur ou un état inattendu et la gère de manière non sécurisée. Elle remplace le SSRF à la dixième place, puisque le SSRF est remonté dans le Contrôle d'accès défaillant.

Le schéma dangereux est la logique fail-open. Imaginez une vérification d'autorisation qui lève une exception quand un service est injoignable, et le code environnant traite l'exception comme « autoriser » au lieu de « refuser ». Le système échoue en faveur de l'attaquant. Cette classe couvre aussi les réponses d'erreur verbeuses qui laissent fuir une trace de pile avec des identifiants de base de données, et les exceptions non gérées qui laissent l'application dans un état à moitié traité et exploitable.

Le lab Flask Error montre comment une exception mal gérée déverse un détail sensible qu'un attaquant peut utiliser, ce qui est le visage quotidien de cette nouvelle catégorie.

Ce qui a changé dans l'OWASP Top 10 2025 par rapport à 2021

Si vous avez appris la liste à partir de l'édition 2021, la majeure partie tient toujours. Le Contrôle d'accès défaillant est toujours premier, et le milieu de la liste a bougé sans trop redescendre. Trois changements valent la peine d'être connus.

Premièrement, deux catégories sont de fait nouvelles. Les Défaillances de la chaîne d'approvisionnement logicielle sont nées de la plus étroite « Composants vulnérables et obsolètes » de 2021 et couvrent désormais toute la chaîne de build et de dépendances. La Mauvaise gestion des conditions exceptionnelles est véritablement nouvelle, ajoutée parce que les défaillances de gestion des erreurs apparaissaient à travers les compromissions sans avoir de place dans la liste.

Deuxièmement, le SSRF a disparu en tant qu'entrée autonome. En 2021, il avait gagné sa propre dixième place grâce à l'enquête ; en 2025, les données l'ont placé à l'intérieur du Contrôle d'accès défaillant, où il trouve sa place en tant que requête que le serveur n'aurait pas dû être autorisé à faire. Il n'est pas devenu moins important, il a été reclassé.

Troisièmement, le classement a été remanié. La Mauvaise configuration de sécurité est passée de la cinquième à la deuxième place, les Défaillances cryptographiques ont glissé de la deuxième à la quatrième, et l'Injection s'est adoucie de la troisième à la cinquième. Voici la comparaison côte à côte.

Comment utiliser l'OWASP Top 10

La liste est un point de départ, pas une ligne d'arrivée. L'OWASP lui-même dit que le Top 10 est un document de sensibilisation, et le traiter comme l'intégralité de votre programme de sécurité est la manière la plus courante de le mal utiliser. La façon dont vous l'appliquez dépend du côté de l'application où vous vous trouvez.

Si vous développez des logiciels

Utilisez le Top 10 comme un prisme de conception et de revue, pas comme une liste de bugs à éliminer à la fin. Avant qu'une fonctionnalité ne soit livrée, posez les questions que la liste implique : celle-ci applique-t-elle le contrôle d'accès sur chaque objet, traite-t-elle toutes les entrées comme hostiles, journalise-t-elle les événements de sécurité, échoue-t-elle en position fermée quand quelque chose casse. Intégrez cela dans la revue de code et vous attrapez des catégories entières avant qu'elles n'existent. Commencez par les fondamentaux dans le cours Bases de la sécurité web, qui couvre comment ces risques se mappent au code que vous écrivez.

Si vous testez des logiciels

Utilisez le Top 10 comme une carte de couverture pour qu'un test ne poursuive pas un seul bug brillant et manque une classe entière. Les professionnels l'associent au plus approfondi OWASP Web Security Testing Guide, qui transforme chaque risque en cas de test spécifiques avec des identifiants que vous pouvez suivre. Pour le flux d'engagement complet autour de ces tests, notre guide de test d'intrusion des applications web montre comment les pièces s'imbriquent dans une évaluation réelle.

La réserve honnête, qui mérite d'être dite clairement : le Top 10 n'est pas exhaustif et n'a jamais été censé l'être. Ce sont les dix risques qui apparaissent le plus, ce qui signifie qu'un attaquant déterminé utilisera volontiers le onzième. Apprenez la liste pour bâtir une fondation, puis continuez au-delà. La valeur est qu'elle donne à tout le monde, développeurs, testeurs et triageurs, un vocabulaire partagé pour les risques qui comptent le plus.

Comment tester l'OWASP Top 10

Vous ne pouvez pas apprendre ces risques en lisant à leur sujet, et vous ne pouvez pas légalement vous entraîner dessus sur des applications que vous ne possédez pas. Il vous faut des cibles construites pour cela. La boîte à outils pour trouver les failles du Top 10 est réduite et vaut la peine d'être bien connue.

• Burp Suite est le proxy d'interception au centre du test web. Vous l'utiliserez pour falsifier le contrôle d'accès, rejouer des charges utiles d'injection et inspecter des jetons. L'édition Community gratuite couvre tout ce dont un débutant a besoin.
• sqlmap automatise l'extraction par injection SQL une fois que vous avez confirmé un point d'injection à la main. Confirmez d'abord manuellement, puis laissez-le faire la partie fastidieuse.
• Un navigateur et ses outils de développement suffisent à trouver un nombre surprenant de failles de contrôle d'accès et de mauvaise configuration. Changez un ID, lisez une erreur verbeuse, remarquez un jeton qui n'expire jamais.
• Nuclei et les scanners de dépendances attrapent vite les classes de mauvaise configuration et de composants vulnérables, là où l'automatisation gagne véritablement sa place.

En pratique, la plupart des vrais résultats viennent d'un humain remarquant quelque chose qu'un scanner ne peut pas juger. Un outil signale qu'une référence à un objet existe ; seule une personne sait que cet objet aurait dû appartenir à quelqu'un d'autre. Cet écart, c'est tout le métier. La façon la plus rapide de construire l'instinct est d'exploiter vous-même chaque risque quelques fois dans un lab contrôlé jusqu'à ce que le schéma soit évident.

Considérations juridiques et éthiques

Les techniques de ce guide sont les mêmes que celles utilisées par les criminels, et la seule chose qui sépare un testeur d'intrusion d'un accusé est la permission. Tester vos propres applications est légal. Tester le site d'une entreprise parce que vous avez repéré un dossier .git ouvert ne l'est pas, aussi évidente que soit la faille ou bonnes que soient vos intentions.

Il y a trois endroits où s'entraîner légalement. Les programmes de bug bounty sur des plateformes comme HackerOne et Bugcrowd accordent la permission de tester dans le cadre de règles publiées. Les engagements rémunérés se déroulent sous un document de périmètre signé. Les plateformes de labs en bac à sable et les événements CTF vous donnent des cibles que la plateforme possède et propose exprès. Tout dans ce guide est destiné à ces trois lieux et nulle part ailleurs.