Qu'est-ce que l'OWASP Top 10 ?
Un développeur pousse du code un vendredi après-midi. Le lundi, un attaquant a manipulé un paramètre d’API, accédé à des dossiers clients et les a exfiltrés via une faille de contrôle d’accès qui aurait pu être évitée par une simple vérification d’autorisation. C’est le type de vulnérabilité que l’OWASP Top 10 vise à prévenir.
L’OWASP Foundation définit l’OWASP Top 10 comme « un document de sensibilisation standard pour les développeurs et la sécurité des applications web. Il représente un large consensus sur les risques de sécurité les plus critiques pour les applications web. » La liste a connu plusieurs éditions, et l’introduction de 2025 a apporté des changements structurels reflétant l’évolution du paysage de la sécurité applicative.
Le NIST et l’équipe MITRE CWE font formellement référence aux catégories de l’OWASP Top 10 dans leurs propres cadres. Si vous gérez un programme de sécurité, développez des applications ou supervisez la gestion des vulnérabilités, l’OWASP Top 10 constitue la base que vos parties prenantes attendent que vous traitiez. Voici ce que couvre l’édition actuelle et comment chaque catégorie s’applique à votre environnement.
Les catégories OWASP Top 10 de 2025
L’édition 2025 a réorganisé les priorités sur la base de données réelles. Voici les dix catégories dans leur classement actuel, avec les changements importants pour votre programme de sécurité.
A01 : Contrôle d’accès défaillant
Toujours en tête, avec 3,73 % des applications testées présentant au moins une faille associée. Un contrôle d’accès défaillant permet aux utilisateurs d’agir au-delà de leurs autorisations prévues, que ce soit en modifiant un paramètre d’URL pour consulter les dossiers d’un autre utilisateur, en escaladant les privilèges via la manipulation d’un jeton JWT, ou en contournant totalement les restrictions au niveau des fonctions. Cela inclut les références directes non sécurisées à des objets (IDOR), les contrôles d’accès manquants et les mauvaises configurations CORS. Le SSRF, auparavant une catégorie distincte, est désormais intégré ici.
A02 : Mauvaise configuration de sécurité
Remontée de la 5e place en 2021, reflétant la dépendance accrue du comportement applicatif moderne à la configuration plutôt qu’au code. Cette catégorie couvre les identifiants par défaut non modifiés, les services inutiles exposés, les messages d’erreur trop détaillés divulguant des traces de pile, et l’absence d’en-têtes de sécurité. Les environnements cloud et les déploiements conteneurisés amplifient le risque, chaque nouveau service, passerelle API ou cluster Kubernetes introduisant sa propre surface de configuration.
A03 : Défaillances de la chaîne d’approvisionnement logicielle
Le changement structurel le plus notable de l’édition 2025. Auparavant limitée aux « composants vulnérables et obsolètes », cette catégorie couvre désormais l’ensemble de l’écosystème des dépendances logicielles, des systèmes de build et de l’infrastructure de distribution. Les attaquants ciblent de plus en plus les pipelines CI/CD, les outils de développement, les registres de conteneurs et les paquets open source largement utilisés plutôt que le code applicatif directement. Malgré une fréquence moindre dans les données, cette catégorie présente les scores moyens d’exploitation et d’impact les plus élevés du jeu de données 2025.
A04 : Défaillances cryptographiques
Renommée depuis « Exposition de données sensibles » pour se concentrer sur les causes profondes plutôt que sur les symptômes. Cette catégorie couvre les données transmises en clair, les fonctions de hachage obsolètes (MD5, SHA1), les mots de passe utilisés comme clés cryptographiques et l’insuffisance d’aléa. Lorsque les protections cryptographiques échouent, les attaquants peuvent intercepter des identifiants en transit, déchiffrer des données stockées ou forger des jetons d’authentification. Ce renommage reflète l’orientation d’OWASP vers le traitement des causes d’exposition plutôt que le simple recensement des incidents après coup.
A05 : Injection
L’injection survient lorsqu’une application transmet une entrée non fiable à un interpréteur sans validation ou échappement approprié, permettant à un attaquant d’exécuter des commandes non prévues. L’injection SQL, le cross-site scripting (XSS), l’injection de commandes système et l’injection LDAP relèvent toutes de cette catégorie. Bien que l’injection soit passée de la 3e à la 5e place en 2025, elle reste l’une des catégories associées au plus grand nombre de CVE et demeure une cause majeure de compromission de données lorsque la gestion des entrées est négligée.
A06 : Conception non sécurisée
Cette catégorie concerne les failles d’architecture et de conception, plutôt que les bogues d’implémentation. Un flux de réinitialisation de mot de passe faible, une étape d’autorisation manquante dans un processus métier ou l’absence de limitation de débit sur un point d’accès sensible sont des décisions de conception, et aucun codage sécurisé ne peut corriger une conception fondamentalement non sécurisée. OWASP a introduit cette catégorie pour mettre l’accent sur la modélisation des menaces, les modèles de conception sécurisés et les activités de sécurité en amont du code. Sa chute de la 4e à la 6e place en 2025 suggère une amélioration progressive du secteur dans ce domaine.
A07 : Défaillances d’identification et d’authentification
Cette catégorie couvre les faiblesses permettant aux attaquants de compromettre des identités : attaques par bourrage d’identifiants, attaques par force brute sur des mots de passe faibles, absence de MFA et failles de gestion de session comme des jetons de session prévisibles ou une invalidation incorrecte. L’analyse d’OWASP note que l’utilisation accrue de cadres d’authentification standardisés a un effet positif sur la fréquence des occurrences, bien que les identifiants volés restent l’un des vecteurs d’accès initiaux les plus courants lors des compromissions.
A08 : Défaillances d’intégrité logicielle ou des données
Cette catégorie cible les hypothèses de confiance dans les mises à jour logicielles, les pipelines CI/CD et la sérialisation des données. Lorsque les applications se mettent à jour automatiquement sans vérifier les signatures, récupèrent des dépendances depuis des sources non vérifiées ou désérialisent des données non fiables sans validation, les attaquants peuvent injecter du code malveillant s’exécutant avec tous les privilèges applicatifs. La catégorie couvre également l’intégrité des pipelines CI/CD, où une étape de build compromise peut livrer des artefacts malveillants en production sans détection.
A09 : Défaillances de journalisation et d’alerte de sécurité
Le renommage de « Défaillances de journalisation et de surveillance de sécurité » est délibéré : « Alerte » remplace « Surveillance » car, selon l’ introduction 2025 d’OWASP, « une excellente journalisation sans alerte a une valeur minimale » pour l’identification des incidents de sécurité. Sans alerte exploitable liée aux sources de logs, les compromissions passent inaperçues alors que les preuves restent stockées. Cette catégorie couvre aussi le manque de détails dans les logs, l’absence de pistes d’audit pour les actions sensibles, et les logs qui n’enregistrent pas les événements d’authentification ou de contrôle d’accès.
A10 : Mauvaise gestion des conditions exceptionnelles
Nouvelle en 2025, cette catégorie traite de la gestion des entrées inattendues, des pénuries de ressources, des délais d’attente ou des défaillances internes par les applications. Une mauvaise gestion des exceptions peut divulguer des données sensibles via des traces de pile détaillées, contourner les contrôles de sécurité via une logique fail-open, ou créer des conditions de déni de service. OWASP a consolidé 24 CWE auparavant dispersées dans les problèmes de « qualité du code » dans cette catégorie, reflétant la reconnaissance croissante que les systèmes fragiles qui échouent de manière non sécurisée constituent une classe de risques distincte et exploitable.
Le tableau ci-dessous résume chaque catégorie et les évolutions de l’édition 2025.
| # | Catégorie | Ce qui a changé en 2025 |
| A01 | Contrôle d’accès défaillant | Inclut désormais le SSRF, auparavant une catégorie distincte |
| A02 | Mauvaise configuration de sécurité | Remontée depuis la 5e place en 2021 |
| A03 | Défaillances de la chaîne d’approvisionnement logicielle | Élargie depuis « Composants vulnérables et obsolètes » pour couvrir l’ensemble de l’écosystème de dépendances |
| A04 | Défaillances cryptographiques | Descendue depuis la 2e place ; l’accent reste mis sur les causes profondes liées au chiffrement |
| A05 | Injection | Passée de la 3e à la 5e place ; reste l’une des catégories les plus testées |
| A06 | Conception non sécurisée | Passée de la 4e à la 6e place ; l’adoption de la modélisation des menaces progresse dans le secteur |
| A07 | Défaillances d’authentification | Position inchangée ; légère mise à jour du nom depuis « Défaillances d’identification et d’authentification » |
| A08 | Défaillances d’intégrité logicielle ou des données | Position inchangée |
| A09 | Défaillances de journalisation et d’alerte de sécurité | Renommée ; « Alerte » remplace « Surveillance » pour refléter le besoin opérationnel |
| A10 | Mauvaise gestion des conditions exceptionnelles | Nouvelle catégorie ; remplace l’ancienne entrée SSRF |
Ces catégories définissent la base. Avant d’examiner comment corriger chacune, il est utile de comprendre pourquoi ces risques spécifiques ont un poids organisationnel.
Pourquoi l’OWASP Top 10 est important
L’écart entre la découverte et l’exploitation des vulnérabilités continue de se réduire, et les applications web restent un point d’entrée principal. Pour votre organisation, l’OWASP Top 10 est important pour trois raisons.
- Priorisation des risques. Vous ne pouvez pas tout corriger en même temps. Le Top 10 vous offre un point de départ basé sur des données, classé selon l’exploitabilité et l’impact, et non la gravité théorique seule.
- Alignement réglementaire. Le NIST CSF maintient des correspondances avec les variantes de l’OWASP Top 10. Lorsque les auditeurs ou régulateurs interrogent votre programme de sécurité applicative, l’OWASP Top 10 est le langage commun.
- Réalité financière. Les défaillances de sécurité dans le contrôle d’accès, la configuration et l’injection peuvent devenir des incidents coûteux. L’OWASP Top 10 aide vos équipes à se concentrer sur les classes de vulnérabilités les plus susceptibles d’avoir un impact opérationnel et métier.
Comprendre pourquoi ces risques comptent est la première étape. La suivante est de savoir comment traiter chacun au niveau du code et de la configuration.
Comment prévenir les vulnérabilités OWASP Top 10
Chaque catégorie de l’OWASP Top 10 comporte des mesures de prévention spécifiques que vos équipes peuvent mettre en œuvre directement.
- A01 : Contrôle d’accès défaillant. Appliquez le refus par défaut sur tous les points d’accès. Validez les permissions côté serveur à chaque requête et centralisez la logique de contrôle d’accès pour une application cohérente dans tout le code. Désactivez l’indexation des répertoires et assurez-vous que les politiques CORS limitent les origines aux domaines de confiance.
- A02 : Mauvaise configuration de sécurité. Supprimez les identifiants par défaut, désactivez les services et fonctionnalités inutilisés, et automatisez les audits de configuration sur tous les environnements. Maintenez les en-têtes de sécurité à jour et assurez-vous que les messages d’erreur restent génériques plutôt que de retourner des traces de pile.
- A03 : Défaillances de la chaîne d’approvisionnement logicielle. Figez les dépendances sur des versions spécifiques et vérifiez leur intégrité avec des signatures cryptographiques ou des sommes de contrôle. Maintenez une liste de matériaux logiciels (SBOM), auditez les plugins CI/CD et les outils de développement, et surveillez les bases de vulnérabilités pour les failles divulguées dans votre arbre de dépendances.
- A04 : Défaillances cryptographiques. Utilisez des standards de chiffrement actuels (TLS 1.2+, AES-256) et retirez les algorithmes obsolètes comme MD5 et SHA1. Stockez les mots de passe avec des fonctions de hachage adaptatives telles que bcrypt ou Argon2. Classez les données selon leur sensibilité pour appliquer le niveau de protection adéquat à chaque actif.
- A05 : Injection. Utilisez des requêtes paramétrées pour toutes les opérations sur la base de données. Validez et assainissez toutes les entrées utilisateur, et échappez les sorties selon le contexte de rendu (HTML, JavaScript, SQL). Appliquez des politiques de sécurité de contenu pour réduire l’impact des XSS.
- A06 : Conception non sécurisée. Réalisez une modélisation des menaces avant d’écrire du code, mettez en place des tests d’abus en parallèle des tests fonctionnels, et appliquez les modèles de conception sécurisés issus des Proactive Controls OWASP. Les défauts de conception coûtent moins cher à corriger en architecture qu’en production.
- A07 : Défaillances d’authentification. Imposer la MFA, mettre en place un throttling des connexions avec un nombre maximal de tentatives, et utiliser des cadres d’authentification standardisés. Invalidez correctement les sessions lors de la déconnexion et du changement de mot de passe.
- A08 : Défaillances d’intégrité logicielle ou des données. Signez cryptographiquement tous les artefacts de build, images de conteneurs et mises à jour logicielles. Validez les entrées lors de la désérialisation et limitez les droits d’écriture sur les pipelines CI/CD aux seuls rôles autorisés.
- A09 : Défaillances de journalisation et d’alerte de sécurité. Configurez des seuils d’alerte exploitables pour les échecs d’authentification, violations de contrôle d’accès et tentatives d’escalade de privilèges. Testez que les alertes se déclenchent dans des conditions réelles, pas seulement que les logs sont collectés.
- A10 : Mauvaise gestion des conditions exceptionnelles. Définissez des modes de défaillance sécurisés qui refusent l’accès en cas d’erreur. Retournez des messages d’erreur génériques aux utilisateurs tout en journalisant des diagnostics détaillés en interne. Gérez explicitement les valeurs nulles, l’épuisement des ressources et les types d’entrées inattendus.
La prévention par catégorie traite les correctifs techniques. L’extension de ces correctifs à l’ensemble de votre organisation pose des défis d’implémentation.
Défis et erreurs courantes dans la mise en œuvre de l’OWASP Top 10
Opérationnaliser l’OWASP Top 10 dans un environnement de production avec des centaines d’applications, des dizaines d’équipes de développement et des cycles de déploiement continus est là où l’implémentation échoue. Voici les schémas les plus dommageables.
- Considérer le Top 10 comme une simple checklist de conformité. OWASP décrit explicitement le Top 10 comme un guide de sensibilisation, et non un programme de sécurité. Pour des tests de vérification, OWASP recommande l’ASVS. Pour la chaîne d’approvisionnement seule, le Top 10 n’est jugé « qu’occasionnellement » suffisant.
- Implémentations fragmentées du contrôle d’accès. Le projet Proactive Controls met en garde contre la multiplication des implémentations de contrôle d’accès dans un même code. Une seule implémentation défaillante reste exploitable même si toutes les autres sont correctes.
- Configurations permissives par défaut. Ne pas appliquer le refus par défaut sur les API REST et webhooks rend tout point d’accès non traité implicitement accessible. Cela concerne aussi bien les services cloud, le RBAC Kubernetes que les passerelles API.
- Autorisation à grande échelle. L’authentification progresse, mais le contrôle d’accès non. Le secteur résout la question « qui êtes-vous ? » mais peine avec « que pouvez-vous faire ? » sur les API et microservices.
- Journalisation sans alerte. Vous pouvez ingérer des téraoctets de logs dans votre SIEM, mais sans seuils d’alerte exploitables, les incidents passent inaperçus alors que les preuves sont stockées.
- Se reposer uniquement sur l’analyse par énumération. Les outils basés sur l’énumération ne trouvent que ce que vous savez déjà rechercher. Les failles logiques, nouvelles mauvaises configurations et faiblesses architecturales nécessitent une analyse comportementale, pas seulement une correspondance de signatures.
Ces schémas persistent lorsque les programmes de sécurité traitent l’OWASP Top 10 comme un audit ponctuel plutôt qu’une pratique opérationnelle continue.
Bonnes pratiques OWASP Top 10
Au-delà des correctifs par catégorie, ces pratiques de programme vous aident à opérationnaliser l’OWASP Top 10 dans toute votre organisation.
- Construisez une bibliothèque centralisée de contrôles de sécurité. Selon les recommandations de programme, définissez des bibliothèques partagées et réutilisables pour l’authentification, l’autorisation, la validation des entrées et la cryptographie. Lorsque chaque équipe développe sa propre implémentation, les incohérences créent des failles exploitables.
- Mappez les Proactive Controls à votre workflow de développement. Les Proactive Controls offrent un complément orienté développeur au Top 10 axé sur les risques. C1 (Contrôle d’accès) correspond à A01, C3 (Validation des entrées) à A05, C5 (Valeurs par défaut sécurisées) à A02. Donnez à vos développeurs des contrôles précis à implémenter, pas seulement des risques à éviter.
- Utilisez l’OWASP ASVS comme base de vérification. Remplacez les tests d’intrusion ad hoc par des exigences ASVS structurées, mappées à chaque catégorie du Top 10. L’ASVS fournit des critères testables en formats CSV et JSON pour une intégration programmatique.
- Intégrez-vous au NIST SSDF pour l’alignement réglementaire. NIST SP 800-218 fait explicitement référence à l’OWASP ASVS, OWASP SAMM et OWASP SCVS comme cadres complémentaires et s’aligne sur les exigences du décret 14028.
Ces pratiques créent la base programmatique. Les tests valident l’efficacité de vos contrôles de prévention.
Comment tester l’OWASP Top 10
Aucun outil unique ne couvre les dix catégories. Un test efficace de l’OWASP Top 10 combine l’analyse statique, les tests dynamiques et l’analyse de composition pour couvrir les risques au niveau du code, à l’exécution et dans les dépendances.
- Analyse statique de sécurité applicative (SAST) analyse le code source à la recherche de schémas d’injection, de faiblesses cryptographiques et de failles d’authentification avant le déploiement. Le SAST détecte les problèmes tôt dans le cycle de développement, lorsque les corrections sont les moins coûteuses.
- Analyse dynamique de sécurité applicative (DAST) teste les applications en fonctionnement pour détecter les lacunes de contrôle d’accès, les mauvaises configurations et les échecs de gestion des erreurs en simulant un trafic d’attaque réel sur des points d’accès actifs. OWASP ZAP est un outil DAST open source largement utilisé et maintenu par la communauté OWASP.
- Analyse de composition logicielle (SCA) identifie les vulnérabilités connues dans les bibliothèques tierces, frameworks et images de conteneurs en comparant votre arbre de dépendances aux bases de vulnérabilités publiées.
- Tests d’intrusion valident votre environnement spécifique, détectant les failles logiques et faiblesses architecturales que les outils automatisés ne voient pas. Mappez les résultats des tests d’intrusion aux exigences ASVS pour une vérification structurée.
Le tableau ci-dessous associe chaque méthode de test aux catégories OWASP Top 10 qu’elle couvre le plus directement.
Méthode | Catégories couvertes | Meilleur usage |
SAST | A04, A05, A07 | Durant le développement, avant la fusion du code |
| DAST | A01, A02, A10 | Sur des applications en fonctionnement en préproduction ou production |
| SCA | A03, A08 | Lors du build et à chaque mise à jour de dépendance |
| Tests d’intrusion | Toutes les 10 catégories | Validation périodique, après les principales mises en production |
La combinaison de ces méthodes vous assure une couverture sur l’ensemble des dix catégories OWASP Top 10. Les outils autonomes comblent l’écart d’exécution entre la détection et la rapidité de réponse.
Points clés à retenir
L’OWASP Top 10 est le cadre de sensibilisation standard du secteur pour les risques de sécurité des applications web, mis à jour en 2025 avec une couverture élargie de la chaîne d’approvisionnement et un nouvel accent sur l’alerte en complément de la journalisation. Le contrôle d’accès défaillant reste la catégorie principale. Chaque catégorie comporte des mesures de prévention concrètes, du contrôle d’accès par défaut à la vérification cryptographique des artefacts.
Une mise en œuvre efficace nécessite des contrôles de sécurité centralisés, des tests en couches via SAST, DAST et SCA, et une investigation autonome qui réduit l’écart entre la vitesse d’exploitation et la vitesse de réponse.
FAQ
L'OWASP Top 10 est un document de sensibilisation standard publié par la Fondation OWASP qui identifie les risques de sécurité les plus critiques pour les applications web.
Basée sur des données réelles de vulnérabilités et des enquêtes communautaires, la liste fournit un classement consensuel utilisé par les développeurs, les équipes de sécurité et les auditeurs comme référence pour les programmes de sécurité applicative. L'édition actuelle a été publiée en 2025.
L'OWASP Top 10 ne suit pas de calendrier de publication fixe. Les mises à jour sont publiées lorsque suffisamment de nouvelles données de vulnérabilité et de retours de la communauté justifient une révision du classement.
Les éditions précédentes ont été publiées en 2013, 2017, 2021 et 2025. Chaque mise à jour reflète les évolutions des modes d'exploitation réels, les changements d'architecture applicative et les nouvelles méthodologies de collecte de données, plutôt que de simples projections théoriques des risques.
Le Top 10 est un document de sensibilisation conçu pour mettre en avant les catégories de risques les plus critiques pour les applications web. L'ASVS (Application Security Verification Standard) fournit des exigences de vérification structurées et testables à trois niveaux d'assurance, ce qui le rend adapté aux tests de sécurité et à la revue de code.
OWASP recommande lui-même l'ASVS pour les revues de conception et les évaluations de sécurité, positionnant le Top 10 comme point d'entrée et l'ASVS comme cadre de vérification.
Le Top 10 des applications web couvre des catégories pertinentes pour les API, en particulier le Contrôle d'accès défaillant (A01) et l'Injection (A05). Cependant, l'OWASP maintient un Top 10 de la sécurité des API distinct avec des catégories spécifiques à l'autorisation des API, à la limitation du débit et au contrôle d'accès au niveau des objets.
Plusieurs risques majeurs liés aux API concernent directement des défaillances d'autorisation similaires à A01. Les organisations exposées de manière significative aux API doivent traiter les deux listes afin d'assurer une couverture adéquate.
La méthodologie 2025 a élargi l'ensemble de données analysé et introduit un cycle de contribution de données plus large, ainsi qu'un volet d'enquête communautaire OWASP pour les risques prospectifs.
La formule de pondération a continué d'équilibrer l'exploitabilité et l'impact technique tout en reflétant un corpus de vulnérabilités plus vaste. Cette expansion méthodologique, et non un simple changement des tendances de la menace, a entraîné plusieurs modifications de classement, notamment la montée de la mauvaise configuration de la sécurité et l'ajout de la gestion inadéquate des conditions exceptionnelles en tant que nouvelle catégorie.
Non. OWASP précise explicitement que le Top 10 est un outil de sensibilisation et de formation de niveau débutant. Pour la sécurité de la chaîne d'approvisionnement uniquement, le Top 10 est qualifié de seulement « Occasionnellement » suffisant.
Un programme complet doit intégrer l'OWASP ASVS pour la vérification, l'OWASP SAMM pour l'évaluation de la maturité, le NIST SSDF pour l'intégration au SDLC, ainsi qu'une protection continue à l'exécution pour couvrir les risques que le Top 10 n'a jamais été conçu pour traiter.
