En bref
L’OWASP Top 10 est un document de sensibilisation qui classe les dix catégories de risques les plus critiques pour les applications web. L’édition 2025 place en tête le contrôle d’accès défaillant, suivi de la mauvaise configuration de sécurité et des défaillances de la chaîne d’approvisionnement logicielle. Ce n’est pas une liste de contrôle exhaustive ni une norme de conformité : c’est un point de départ pour orienter les tests, la revue de code et la formation des équipes.
Qu’est-ce que l’OWASP Top 10, et à quoi sert-il ?
L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie des ressources ouvertes sur la sécurité des applications. Son Top 10 est un consensus sur les risques les plus critiques, construit à partir de données de tests fournies par des organisations et d’une enquête auprès de la communauté. Il est mis à jour périodiquement ; l’édition en vigueur est celle de 2025.
Il sert à trois usages : former les développeurs aux familles de défauts, orienter un test d’intrusion ou une revue de code, et fournir un vocabulaire commun entre équipes et prestataires. Il ne remplace pas un test sur votre application : il décrit des catégories, pas vos défauts.
Quelles sont les dix catégories de l’édition 2025 ?
- 1A01, contrôle d’accès défaillant : l’application ne vérifie pas correctement ce que l’utilisateur a le droit de faire ou de lire. L’édition 2025 y intègre les falsifications de requêtes côté serveur (SSRF). Cela recouvre les IDOR, qui permettent de lire l’objet d’un autre utilisateur en changeant un identifiant.
- 2A02, mauvaise configuration de sécurité : paramètres par défaut, services inutiles activés, messages d’erreur trop bavards, droits de stockage trop larges. Cette catégorie progresse parce qu’une part croissante du comportement d’une application dépend de sa configuration.
- 3A03, défaillances de la chaîne d’approvisionnement logicielle : élargissement de l’ancienne catégorie des composants vulnérables et obsolètes, à toute la chaîne des dépendances, des systèmes de construction et de distribution.
- 4A04, défaillances cryptographiques : absence de chiffrement, algorithmes faibles, clés mal gérées, données sensibles exposées en clair.
- 5A05, injection : des données non fiables sont interprétées comme du code ou des commandes. L’injection SQL et le cross-site scripting en font partie.
- 6A06, conception non sécurisée : le défaut est dans la conception, pas dans le code. Aucune implémentation parfaite ne corrige un parcours qui permet, par construction, un abus.
- 7A07, défaillances d’authentification : mots de passe faibles autorisés, absence de limitation des tentatives, gestion de session défectueuse, réinitialisation de mot de passe contournable.
- 8A08, défaillances d’intégrité des logiciels ou des données : confiance accordée à du code, des mises à jour ou des données sans vérification d’intégrité, comme une désérialisation de données non fiables.
- 9A09, défaillances de journalisation et d’alerte : les événements importants ne sont pas enregistrés, ou pas surveillés, donc une attaque passe inaperçue. L’édition 2025 insiste sur l’alerte, pas seulement sur le journal.
- 10A10, mauvaise gestion des conditions exceptionnelles : l’application réagit mal à une erreur ou à un état inattendu, par exemple en s’ouvrant par défaut au lieu de refuser, ou en révélant des informations internes.
Quelles nouveautés dans l’édition 2025 ?
Selon l’OWASP, l’édition 2025 compte deux nouvelles catégories et une consolidation. Les deux nouvelles sont les défaillances de la chaîne d’approvisionnement logicielle : définition (A03) et la mauvaise gestion des conditions exceptionnelles (A10). La consolidation est l’intégration de la falsification de requêtes côté serveur dans le contrôle d’accès défaillant. Le contrôle d’accès reste premier.
Deux autres changements d’intitulé sont instructifs : « défaillances d’authentification » remplace « défaillances d’identification et d’authentification », et « journalisation et alerte » remplace « journalisation et surveillance », pour souligner qu’un journal que personne ne lit ne protège rien.
Que ne dit pas le classement ?
- Il ne dit pas ce qui est le plus risqué pour vous : une application sans paiement ni données personnelles n’a pas le même profil qu’une plateforme financière.
- Il ne couvre que les applications web. Pour les API, l’OWASP maintient un classement distinct, l’API Security Top 10, qui met en première place l’autorisation au niveau des objets (BOLA).
- Il n’est pas un standard de conformité : être « conforme à l’OWASP Top 10 » ne veut rien dire de précis. Si un client l’exige, demandez ce qu’il entend vérifier.
- Il ne remplace pas un référentiel de vérification détaillé, comme l’ASVS, qui énumère des exigences testables.
Par où commencer quand on développe ?
- 1Centralisez le contrôle d’accès côté serveur et testez-le automatiquement avec deux comptes appartenant à deux organisations.
- 2Revoyez la configuration par défaut de chaque environnement et supprimez ce qui n’est pas utilisé.
- 3Inventoriez vos dépendances et sachez qui les met à jour, avec quel délai.
- 4Utilisez des requêtes paramétrées et des bibliothèques d’authentification éprouvées plutôt que du code maison.
- 5Journalisez les événements de sécurité, branchez une alerte dessus et vérifiez qu’elle sonne lors d’un test.
À retenir
- 1L’OWASP Top 10 est un document de sensibilisation, pas une norme de conformité ni une liste exhaustive.
- 2Le contrôle d’accès défaillant reste en tête de l’édition 2025 ; il se vérifie avec un humain, pas avec un scanner.
- 3L’édition 2025 ajoute la chaîne d’approvisionnement logicielle et les conditions exceptionnelles.
- 4Pour les API, utilisez le classement dédié de l’OWASP, qui place l’autorisation par objet en première place.
Sources citées
- OWASP Top 10:2025, OWASP Foundation
- OWASP Top 10:2025, Introduction, OWASP Foundation
- Web Security Testing Guide, OWASP Foundation
Comment un test d’intrusion utilise-t-il le Top 10 ?
Un test d’intrusion n’est pas une vérification dix cases. Les guides de test, comme le Web Security Testing Guide de l’OWASP, organisent le travail par familles de vérifications plus fines que le Top 10 : gestion des identités, authentification, autorisation, gestion de session, validation des entrées, logique métier, API. Le Top 10 sert de grille de restitution : chaque constat est rattaché à une catégorie pour que l’équipe comprenne la famille de défaut.
Les catégories se vérifient de façon très inégale par les outils. Les scanners détectent assez bien une partie des injections et des composants obsolètes. Ils ne détectent pas le contrôle d’accès défaillant, qui demande deux comptes de test et la compréhension du métier, ni la conception non sécurisée, ni les abus de logique. C’est pourquoi la première catégorie du classement exige un travail humain.