OWASP Top 10 : la liste complète et commentée
OWASP Top 10 : comprendre la référence en sécurité des applications web
L’OWASP Top 10 classe les grandes familles de risques qui menacent les applications web. Ce référentiel, élaboré par la communauté de l’Open Worldwide Application Security Project, aide les équipes à repérer des faiblesses fréquentes et à parler de sécurité avec des repères communs.
Il ne constitue ni un inventaire exhaustif de toutes les attaques ni une certification de sécurité. Une application qui couvre les dix catégories peut encore présenter des risques propres à son métier, à son architecture ou à son environnement d’exploitation.
La version 2025 met davantage l’accent sur des causes systémiques, comme la chaîne d’approvisionnement logicielle et la gestion des erreurs. Elle intègre également les requêtes côté serveur non maîtrisées au contrôle d’accès, tandis que les conditions exceptionnelles font l’objet d’une catégorie dédiée.
Pour une équipe qui prépare une nouvelle fonctionnalité, la valeur du classement tient à son usage pratique : identifier les risques dès la conception, les tester pendant le développement, puis surveiller les comportements anormaux en production. Il sert de point de départ pour prioriser le travail, pas de raccourci qui dispenserait d’analyser le contexte.
Une entreprise fictive, Boréal, développe un portail permettant à ses clients de consulter des factures. Le référentiel lui donne un cadre pour examiner les droits d’accès, le stockage des données, les composants utilisés et la façon dont le système réagit à une erreur.
Les responsables techniques peuvent ainsi transformer une discussion générale sur la sécurité en décisions vérifiables. Le classement devient utile lorsque chaque risque est relié à une fonction précise, à un scénario d’abus plausible et à une mesure de réduction applicable.
Quelques repères évitent de confondre ce cadre avec une recette universelle :
- Un classement des risques applicatifs, et non une garantie de sécurité
- Un vocabulaire commun entre développeurs, auditeurs et responsables sécurité
- Un support de priorisation, complété par l’analyse du contexte métier
- Un référentiel à intégrer au cycle de développement, pas seulement à l’audit final
La lecture des catégories doit aussi tenir compte des évolutions entre éditions. Le contrôle d’accès demeure central, mais la sécurité logicielle concerne désormais autant les configurations cloud et les pipelines de livraison que le code visible par l’utilisateur.
Cette évolution change la manière de répartir les responsabilités. Les équipes de développement ne peuvent pas corriger seules une configuration d’infrastructure risquée, pas plus que les équipes d’exploitation ne peuvent compenser une logique d’autorisation défectueuse dans une application.
Selon l’OWASP, le Top 10 est un document de sensibilisation destiné à attirer l’attention sur les risques majeurs. Pour approfondir les exigences et les méthodes de vérification, les équipes peuvent également consulter des ressources spécialisées comme l’ASVS et le Testing Guide.
Comprendre ce rôle de boussole permet ensuite d’examiner concrètement les premières catégories, où les erreurs d’autorisation, de configuration et de traitement des entrées peuvent exposer directement les données.
OWASP Top 10 : contrôle d’accès, configuration et injections
Parce que le référentiel sert à guider des vérifications concrètes, ses premières catégories méritent une attention particulière : elles touchent aux autorisations, aux réglages de l’application et aux données fournies par les utilisateurs.
Le contrôle d’accès défaillant reste en tête dans la version 2025. Une faille peut permettre à un client de consulter la facture d’un autre en modifiant un identifiant dans une adresse web, ou à un compte ordinaire d’atteindre une fonction réservée à l’administration.
Une interface qui masque un bouton ne constitue pas une protection suffisante : un utilisateur peut envoyer directement une requête au serveur. Boréal doit donc vérifier les droits côté serveur pour chaque opération sensible, appliquer le refus par défaut et éviter d’accorder des privilèges plus larges que nécessaire.
La catégorie inclut aussi les risques liés aux requêtes initiées par le serveur à partir d’adresses fournies par un utilisateur. Si l’application peut atteindre des ressources internes, un attaquant pourrait détourner cette capacité pour explorer des services normalement inaccessibles.
La mauvaise configuration de sécurité occupe la deuxième place du classement 2025. Un environnement de test laissé accessible, des identifiants par défaut, des services inutiles ouverts ou des messages d’erreur trop détaillés peuvent révéler des informations utiles à un attaquant.
Les environnements cloud rendent ces erreurs particulièrement faciles à multiplier : un stockage rendu public ou un rôle doté de permissions excessives peut exposer des données sans qu’une ligne de code vulnérable soit nécessaire. Des configurations standardisées et examinées automatiquement réduisent ce risque.
La troisième catégorie concerne les défaillances de la chaîne d’approvisionnement logicielle. Elle élargit la vigilance autrefois centrée sur les composants vulnérables ou obsolètes aux dépendances, aux systèmes de construction et aux mécanismes de distribution.
Une bibliothèque compromise ou un pipeline de livraison mal protégé peut introduire du code dangereux avant même son déploiement. L’inventaire des dépendances, les vérifications de provenance et la restriction des accès aux outils de construction aident à réduire cette exposition.
Les deux catégories suivantes complètent ce premier groupe : les défaillances cryptographiques exposent des données lorsque leur chiffrement ou leur stockage est inadéquat, tandis que l’injection survient lorsqu’une donnée contrôlée par l’utilisateur est interprétée comme une commande ou une instruction.
Le tableau distingue les risques et les vérifications utiles au développement :
| Catégorie | Exemple de risque | Vérification ou mesure |
|---|---|---|
| Contrôle d’accès défaillant | Accès à la facture d’un autre compte | Contrôles d’autorisation côté serveur |
| Mauvaise configuration | Service de test exposé publiquement | Durcissement et audit des paramètres |
| Chaîne d’approvisionnement | Dépendance ou pipeline compromis | Inventaire, vérification et contrôle des accès |
| Défaillances cryptographiques | Données sensibles transmises sans protection adéquate | Chiffrement adapté et gestion sécurisée des clés |
| Injection | Entrée interprétée comme une requête exécutable | Requêtes paramétrées et validation côté serveur |
Selon l’OWASP, les requêtes préparées constituent une défense importante contre les injections SQL. Elles séparent les instructions de la base de données des valeurs fournies, ce qui limite les risques associés à une entrée interprétée comme une partie de la commande.
Pour les mots de passe, le chiffrement réversible n’est généralement pas le bon mécanisme : on utilise un hachage conçu pour cet usage, avec une fonction reconnue et des paramètres appropriés. Les secrets applicatifs, eux, doivent être conservés dans un dispositif de gestion adapté, plutôt que dans le code source.
Une vérification pratique des cinq premières catégories peut s’appuyer sur ces actions :
- Tester les permissions avec plusieurs rôles et comptes distincts
- Examiner les configurations de production, de test et du cloud
- Inventorier les dépendances et surveiller leurs vulnérabilités connues
- Protéger les données sensibles en transit et au repos
- Remplacer les requêtes dynamiques par des requêtes paramétrées
Ces contrôles réduisent plusieurs risques directs, mais la robustesse dépend également des choix d’architecture, des mécanismes d’authentification et de la capacité à préserver l’intégrité du logiciel.
OWASP Top 10 : conception, authentification et gestion des erreurs
Après les risques liés aux accès et aux entrées, le classement élargit l’analyse aux décisions prises avant le codage et aux mécanismes qui maintiennent l’application fiable au fil de son fonctionnement.
La conception non sécurisée désigne des faiblesses intégrées aux choix d’architecture ou aux règles métier. Si un système autorise une opération dès qu’un formulaire est envoyé, sans vérifier côté serveur que l’utilisateur en a le droit, une correction cosmétique de l’interface ne résoudra pas le problème de fond.
La modélisation des menaces aide à faire apparaître ces scénarios avant leur mise en production. Une équipe peut dessiner les flux de données, repérer les actifs sensibles et examiner comment un utilisateur malveillant pourrait détourner chaque fonction importante.
L’authentification défaillante couvre notamment les protections insuffisantes contre les essais répétés, les mots de passe faibles et la mauvaise gestion des sessions. Un compte de gestionnaire sans authentification multifacteur peut devenir une cible privilégiée, même lorsque les autres éléments du portail sont bien protégés.
Des limites de tentatives, une gestion rigoureuse des sessions et l’authentification multifacteur pour les comptes sensibles renforcent la défense. Les équipes doivent également invalider les sessions devenues obsolètes, par exemple après un changement de mot de passe ou une déconnexion.
Les défaillances d’intégrité apparaissent lorsque le logiciel, ses dépendances ou ses données ne sont pas vérifiés correctement. Une mise à jour sans contrôle de signature ou un pipeline de construction accessible à trop de personnes peut introduire des modifications non autorisées.
La journalisation et surveillance insuffisantes constituent un autre angle mort. Si l’application ne conserve pas les événements importants ou si personne ne traite les alertes, des échecs de connexion répétés ou des changements inhabituels peuvent passer inaperçus.
Enfin, la gestion incorrecte des conditions exceptionnelles concerne les erreurs et états imprévus. Un système qui accorde un accès par défaut lorsqu’un service d’autorisation tombe en panne adopte un comportement permissif au moment même où il devrait se protéger.
Le tableau ci-dessous associe ces catégories à une action de prévention :
| Catégorie | Faiblesse observée | Pratique préventive |
|---|---|---|
| Conception non sécurisée | Règle métier contournable | Modélisation des menaces et revue d’architecture |
| Authentification défaillante | Compte sensible sans protection renforcée | Multifacteur et gestion fiable des sessions |
| Défaillance d’intégrité | Mise à jour non vérifiée | Contrôle des signatures et des artefacts |
| Journalisation et surveillance insuffisantes | Activité suspecte non détectée | Collecte centralisée et alertes exploitables |
| Gestion des conditions exceptionnelles | Accès accordé après une erreur | Comportement sécurisé en cas de défaillance |
Selon l’OWASP, une gestion prudente des erreurs évite de divulguer des informations techniques sensibles aux utilisateurs. Les détails utiles au diagnostic peuvent être conservés dans des journaux protégés, tandis que l’interface affiche un message compréhensible et non révélateur.
Pour Boréal, cela signifie qu’une panne du service de facturation ne doit ni exposer des traces techniques ni permettre d’accéder aux données sans vérification. Le système doit échouer de façon sûre, signaler l’incident et permettre aux équipes de comprendre ensuite ce qui s’est produit.
Pour examiner ces catégories dans une application réelle, les équipes peuvent notamment vérifier les éléments suivants :
- Les règles métier et les menaces sont examinées dès la conception
- Les comptes sensibles disposent de protections d’authentification renforcées
- Les mises à jour et artefacts font l’objet de contrôles d’intégrité
- Les événements importants déclenchent des alertes suivies par une équipe
- Les erreurs ne révèlent pas de détails internes ni d’accès permissifs
Ces mesures deviennent plus efficaces lorsqu’elles sont réparties dans le cycle de développement, plutôt que concentrées dans un audit réalisé juste avant la mise en ligne.
Intégrer l’OWASP Top 10 au cycle de développement
Les catégories décrivent des risques différents, mais elles convergent vers une même exigence : faire de la sécurité une pratique régulière du développement, de la livraison et de l’exploitation.
À la conception, l’équipe définit les actifs à protéger, les rôles des utilisateurs et les flux entre composants. Une revue d’architecture peut révéler qu’une fonction essentielle dépend d’un service interne trop accessible ou qu’une règle d’autorisation repose uniquement sur l’interface.
Pendant le développement, les revues de code et les outils d’analyse statique peuvent aider à détecter certaines erreurs avant leur fusion. Ils ne remplacent pas la compréhension du contexte : un outil peut repérer une requête risquée, mais ne sait pas toujours si un utilisateur devrait pouvoir effectuer une opération particulière.
Les analyses de dépendances examinent les bibliothèques utilisées et leurs vulnérabilités connues. Elles gagnent à être intégrées au processus d’intégration continue, avec une procédure claire pour évaluer les alertes, mettre à jour un composant ou documenter une exception temporaire.
En phase de test, l’analyse dynamique observe le comportement d’une application en fonctionnement. Des tests manuels complètent ces contrôles en explorant les enchaînements d’actions, les rôles et les cas métier qu’un scanner automatique ne couvre pas toujours correctement.
Selon l’OWASP, le Top 10 sensibilise aux catégories importantes, tandis que des ressources comme l’ASVS donnent des exigences de vérification plus détaillées. Les équipes peuvent s’appuyer sur des outils tels qu’OWASP ZAP ou Dependency-Check, en évaluant leur pertinence et leurs limites.
À la livraison, la vérification des paramètres, des secrets et des artefacts contribue à limiter les erreurs de configuration et d’intégrité. En production, la surveillance des journaux, la gestion des correctifs et l’analyse des incidents alimentent les améliorations du cycle suivant.
Pour éviter que ces actions restent théoriques, Boréal peut rattacher chaque contrôle à un responsable et à une étape de livraison. Une alerte sur une dépendance, par exemple, doit avoir un propriétaire, un niveau de priorité et une échéance de traitement définis.
Un cycle de travail cohérent peut inclure les étapes suivantes :
- Conception : cartographier les actifs, les rôles et les menaces
- Développement : former les équipes et examiner les changements sensibles
- Tests : combiner analyses automatisées et vérifications manuelles
- Livraison : vérifier les configurations, secrets et artefacts logiciels
- Production : surveiller les événements et corriger les faiblesses identifiées
Les outils ne produisent de valeur que si leurs résultats sont traités. Une liste d’alertes ignorées peut même masquer les risques prioritaires, tandis qu’un processus court et régulier facilite la correction avant que le problème ne s’accumule.
La fréquence des tests doit refléter la vitesse des changements et la sensibilité des données. Une application qui reçoit souvent de nouvelles fonctions n’a pas intérêt à attendre un audit annuel pour repérer une permission nouvellement exposée.
Le cadre devient alors une méthode de collaboration : les développeurs corrigent les défauts de code, les équipes d’infrastructure réduisent les erreurs de configuration et les responsables sécurité suivent les risques résiduels.
Une fois ces pratiques intégrées, l’étape suivante consiste à organiser les audits et à prioriser les corrections selon leur impact concret, plutôt que selon le seul nombre d’alertes détectées.
Audit OWASP Top 10 : tester et prioriser les corrections
Lorsque les pratiques de développement sont établies, un audit permet de vérifier si elles résistent à des scénarios d’attaque réalistes et si les corrections répondent effectivement aux risques observés.
Un audit fondé sur l’OWASP Top 10 examine les catégories pertinentes pour l’application : droits d’accès, configuration, dépendances, protection des données, authentification et traitement des erreurs. Son périmètre dépend de l’architecture, des fonctionnalités, des environnements concernés et des objectifs convenus.
Un test utile ne se contente pas de signaler qu’un endpoint existe. Il vérifie, par exemple, si un utilisateur authentifié peut lire ou modifier une ressource appartenant à un autre compte, puis documente les conditions nécessaires à l’exploitation et les données concernées.
Les résultats doivent distinguer le risque technique de son impact métier. Une faiblesse sur une fonction rarement utilisée mais donnant accès à des données très sensibles peut mériter une priorité supérieure à un défaut plus visible, mais difficilement exploitable.
Une notation comme le CVSS peut contribuer à comparer les vulnérabilités, mais elle ne remplace pas l’évaluation du contexte. Les équipes doivent aussi considérer l’exposition réseau, les privilèges nécessaires, les protections déjà en place et les conséquences pour les utilisateurs.
Un rapport exploitable décrit le problème, les conditions de reproduction, les preuves nécessaires et une recommandation de correction. Il peut aussi préciser les limites du test, afin que personne ne confonde l’absence de découverte avec une garantie absolue.
Pour Boréal, un accès indu aux factures pourrait entraîner une exposition de données personnelles. L’équipe traiterait donc d’abord la règle d’autorisation, puis retesterait plusieurs profils afin de confirmer que le correctif bloque les accès croisés sans empêcher les opérations légitimes.
Les corrections gagnent à être suivies comme des tâches ayant un responsable, une échéance et un moyen de validation. Une faille corrigée sans test de non-régression peut réapparaître dans une évolution ultérieure ou être déplacée vers un autre point d’accès.
Une priorisation claire s’appuie sur plusieurs critères complémentaires :
- La sensibilité des données et des fonctions concernées
- La facilité d’exploitation et les privilèges requis
- L’exposition de l’application et des composants touchés
- Les conséquences possibles pour les clients et l’activité
- La capacité à vérifier le correctif après son déploiement
Un audit ponctuel gagne en valeur lorsqu’il s’inscrit dans un programme continu. Les changements importants, l’ajout de nouveaux services ou une modification des rôles utilisateurs peuvent justifier de nouvelles vérifications ciblées.
Le classement n’impose pas un outil unique ni un ordre de correction identique à toutes les organisations. Il aide plutôt à structurer une analyse, à expliquer les décisions et à éviter que des risques connus restent sans propriétaire.
Les équipes peuvent aussi s’appuyer sur des tests automatisés pour les contrôles répétables, puis réserver les vérifications humaines aux scénarios complexes et à la logique métier. Cette combinaison limite les oublis sans confondre couverture technique et sécurité réelle.
En pratique, une application plus sûre résulte de corrections vérifiées, de responsabilités explicites et d’une surveillance durable. L’OWASP Top 10 fournit un langage commun pour engager ce travail, tandis que l’analyse du contexte détermine les priorités concrètes.
Une démonstration d’outil de test peut aider les équipes à comprendre les contrôles automatisés, à condition de compléter les résultats par une validation humaine et des essais autorisés sur leurs propres applications.
Source : OWASP, « Top 10:2025 », documentation officielle.
