L’OWASP Top 10 est la liste de référence des dix catégories de risques les plus critiques pour les applications web, publiée par la fondation OWASP et révisée en 2025. En tête figurent le contrôle d’accès défaillant (un utilisateur accède à des données ou fonctions qui ne lui sont pas destinées), les erreurs de configuration et les failles de la chaîne d’approvisionnement (composants tiers vulnérables ou compromis). Pour un dirigeant, l’enjeu n’est pas de comprendre chaque faille technique, mais de s’assurer que son prestataire les traite par la conception, les tests et la maintenance, et de savoir quelles questions poser pour le vérifier.
Qu’est-ce que l’OWASP Top 10, et pourquoi s’y intéresser ?
L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui produit des ressources ouvertes sur la sécurité des applications. Son Top 10 est devenu un langage commun entre développeurs, auditeurs, acheteurs et assureurs : quand un cahier des charges ou un questionnaire de sécurité mentionne « la couverture de l’OWASP Top 10 », c’est à cette liste qu’il fait référence.
La version 2025 repose sur une base de données importante. D’après l’introduction officielle, les données ont été fournies pour plus de 2,8 millions d’applications et 589 types de faiblesses (CWE) ont été analysés, contre près de 400 en 2021. Deux catégories ont été retenues grâce à l’enquête menée auprès de la communauté, en complément des données.
Pourquoi un dirigeant devrait-il s’y intéresser ? Parce que la plupart des incidents de sécurité applicative ne viennent pas d’attaques sophistiquées, mais de défauts ordinaires que ce classement décrit précisément. Et parce que ces défauts coûtent beaucoup moins cher à éviter à la conception qu’à corriger après une fuite.
Les dix risques de 2025, traduits en langage clair
Le classement 2025 se présente ainsi :
| Rang | Catégorie | En une phrase |
|---|---|---|
| A01 | Contrôle d’accès défaillant | Un utilisateur voit ou modifie ce qui ne lui est pas destiné |
| A02 | Mauvaise configuration de sécurité | Réglages par défaut, options de débogage, accès d’administration laissés ouverts |
| A03 | Défaillances de la chaîne d’approvisionnement | Bibliothèques, outils de build ou de déploiement vulnérables ou compromis |
| A04 | Défaillances cryptographiques | Données sensibles mal chiffrées ou pas chiffrées du tout |
| A05 | Injection | Des données saisies sont interprétées comme des commandes (SQL, scripts) |
| A06 | Conception non sécurisée | Une faille dans la logique même du processus, pas dans le code |
| A07 | Défaillances d’authentification | Mots de passe faibles acceptés, sessions mal gérées, pas de double authentification |
| A08 | Défaillances d’intégrité des données ou du code | Mises à jour ou données acceptées sans vérification de leur origine |
| A09 | Défaillances de journalisation et d’alerte | Une attaque passe inaperçue faute de traces et d’alertes |
| A10 | Mauvaise gestion des situations exceptionnelles | Une erreur imprévue laisse l’application dans un état ouvert ou révèle des informations |
Par rapport à 2021, la mauvaise configuration monte de la 5e à la 2e place, l’injection descend de la 3e à la 5e, la faille SSRF (une requête forgée qui fait appeler par le serveur une adresse interne) est intégrée au contrôle d’accès, et deux catégories font leur apparition : la chaîne d’approvisionnement, qui élargit l’ancienne catégorie des composants obsolètes, et la gestion des situations exceptionnelles.
A01, le contrôle d’accès : le risque numéro un, expliqué par l’exemple
Le contrôle d’accès est l’ensemble des règles qui déterminent qui peut voir et faire quoi dans l’application. Selon l’OWASP, 100 % des applications testées présentaient une forme de contrôle d’accès défaillant. Trois scénarios décrits par la fondation parlent d’eux-mêmes :
- L’identifiant modifiable : un client consulte sa facture à l’adresse
.../factures/1042. Il remplace 1042 par 1043 et voit la facture d’un autre client, parce que le serveur ne vérifie pas que la facture lui appartient. - La page d’administration devinable : une page
/adminn’apparaît pas dans les menus, mais n’importe quel utilisateur connecté qui tape l’adresse y accède, car le serveur ne contrôle pas son rôle. - Le contrôle uniquement dans l’interface : un bouton est masqué pour les utilisateurs non autorisés, mais l’action correspondante reste accessible en appelant directement le serveur.
La règle à retenir : tout droit doit être vérifié par le serveur, à chaque requête. Masquer un bouton n’est pas une mesure de sécurité. Dans un portail client B2B ou un extranet multi-entreprises, ce cloisonnement entre comptes est le premier point à tester.
Pourquoi la chaîne d’approvisionnement monte en puissance
Une application web moderne assemble des centaines de composants open source et repose sur des outils de construction et de déploiement automatisés. La catégorie A03 couvre les risques de cet écosystème : une bibliothèque qui contient une faille connue, un composant abandonné par ses mainteneurs, une dépendance piratée qui diffuse du code malveillant, une chaîne de déploiement mal protégée. L’OWASP précise que cette catégorie a été massivement désignée comme une préoccupation majeure par la communauté.
Pour une PME ou une ETI, la conséquence est contractuelle autant que technique : une application livrée puis jamais mise à jour devient vulnérable avec le temps, même si son code n’a pas changé. La mise à jour régulière des dépendances doit donc figurer dans le contrat de maintenance et de TMA, avec un délai de traitement des failles critiques. Les composants non suivis sont aussi une forme de dette technique, qui s’accumule silencieusement.
Ce que la sécurité change dans la conduite d’un projet
Les dix risques ne se traitent pas tous au même moment du projet. Voici où chacun se joue :
| Phase du projet | Risques principalement traités | Pratiques attendues |
|---|---|---|
| Cadrage et conception | A01, A06, A10 | Matrice des droits, analyse des scénarios d’abus, règles de comportement en cas d’erreur |
| Développement | A04, A05, A07, A08 | Requêtes paramétrées, bibliothèques d’authentification éprouvées, chiffrement standard, revues de code |
| Construction et déploiement | A02, A03, A08 | Analyse automatique des dépendances, configuration de production durcie, secrets hors du code |
| Exploitation | A09, A03 | Journalisation, alertes, mises à jour, plan de réponse aux incidents |
Deux catégories méritent une attention particulière des dirigeants, car elles relèvent de choix fonctionnels :
- La conception non sécurisée (A06) : une procédure de réinitialisation de mot de passe qui repose sur une question dont la réponse est publique, un processus de commande qui permet de modifier le prix côté navigateur, un parcours de validation qui peut être contourné. Ces failles naissent dans les ateliers de conception, pas dans le code.
- La journalisation et l’alerte (A09) : sans traces exploitables, une intrusion peut durer des mois sans être détectée. C’est aussi ce qui permet de répondre aux obligations de notification en cas de violation de données, comme nous l’expliquons dans notre article sur le RGPD dans une application métier.
Pour aller plus loin que le Top 10, l’OWASP publie l’ASVS (Application Security Verification Standard), un référentiel d’exigences vérifiables organisé par niveaux. Il est utile pour formaliser les exigences de sécurité dans un contrat ou un cahier des charges.
Les questions à poser à votre prestataire
Vous n’avez pas besoin de lire le code pour évaluer le sérieux d’un prestataire. Ces questions suffisent à distinguer une démarche structurée d’une promesse vague, et complètent celles de notre guide pour choisir une agence de développement web :
- Sur quel référentiel vous appuyez-vous ? Une réponse précise (OWASP ASVS, recommandations de l’ANSSI) vaut mieux qu’un « on fait attention ».
- Comment les droits sont-ils vérifiés ? La réponse attendue : côté serveur, de façon centralisée, avec des tests automatisés qui vérifient qu’un utilisateur ne peut pas accéder aux données d’un autre.
- Comment suivez-vous les dépendances ? Analyse automatique des composants vulnérables à chaque livraison, et mise à jour planifiée.
- Quels tests de sécurité sont intégrés au cycle de livraison ? Analyse statique du code, tests de contrôle d’accès, tests d’intrusion avant les mises en production majeures.
- Qu’est-ce qui est journalisé, et qui reçoit les alertes ?
- Que se passe-t-il si une faille est découverte après la livraison ? Délai de correction, responsabilité, information du client.
- Où sont stockés les secrets (mots de passe de bases de données, clés d’API) ? Jamais dans le code source.
Si votre entreprise entre dans le champ de la directive européenne NIS2, la sécurité du développement et la gestion des vulnérabilités deviennent en outre des obligations explicites : nous les détaillons dans notre article sur NIS2 pour les PME et ETI.
Par où commencer si votre application existe déjà ?
Pour une application en production, l’ordre de priorité raisonnable est le suivant :
- Inventorier les composants et leurs versions, et identifier ceux qui ont des failles connues.
- Tester le cloisonnement : un utilisateur peut-il accéder aux données d’un autre en modifiant un identifiant ?
- Vérifier la configuration de production : mode débogage désactivé, accès d’administration protégés, double authentification pour les comptes à privilèges.
- Mettre en place la journalisation des connexions, des actions sensibles et des erreurs, avec des alertes.
- Planifier un test d’intrusion une fois ces bases posées, pour qu’il révèle autre chose que des évidences.
La sécurité fait partie de la qualité d’une application web sur mesure, au même titre que les performances ou l’ergonomie. Vous voulez faire le point sur une application existante ou intégrer ces exigences dans un nouveau projet ? Décrivez votre situation dans notre diagnostic de projet : nous revenons vers vous avec une première analyse.
