Cybersécurité · fiche technologique
OWASP Top 10Fiche technologique · Cybersécurité
Comprendre l'OWASP Top 10 pour vos applications web
Le Top 10 de l'OWASP recense dix grandes familles de risques pour les applications web. C'est un document de sensibilisation, pas une norme de conformité. Voici comment le lire, ce que change l'édition 2025 et comment nous nous en servons pour cadrer un audit.
Le besoin
Ce qu'il faut savoir avant de citer le Top 10.
Vous croisez le Top 10 dans un devis, un rapport ou un appel d'offres. Mieux vaut savoir ce qu'il garantit, et surtout ce qu'il ne garantit pas.
Le Top 10 est un projet de l'OWASP, communauté dédiée à la sécurité des applications. Il se présente lui-même comme un document de sensibilisation : un consensus sur dix familles de risques parmi les plus critiques pour les applications web. L'édition en vigueur est celle de 2025. La précédente, publiée en 2021, reste très citée dans les contrats et les rapports.
Ce n'est ni une norme ni un référentiel de conformité. Il n'a pas été conçu pour qu'on s'y déclare « conforme ». Le document lui-même décourage toute revendication de couverture complète de la liste. Sa vraie valeur est ailleurs : donner à ceux qui commandent, écrivent et contrôlent une application un vocabulaire commun pour parler du risque.
Chaque catégorie regroupe de nombreuses faiblesses précises : l'édition 2025 en rassemble 248 sous ses dix intitulés. Lire une catégorie, c'est donc choisir par où commencer, pas cocher une case. La manière dont nous l'exploitons pour cadrer et restituer un contrôle est détaillée dans notre audit de sécurité des applications web.
Un langage partagé
Direction, équipe technique et prestataire désignent la même famille de risques par le même nom : les priorités se discutent sans malentendu.
Un point de départ
Dix catégories ne couvrent pas tout. Une règle commerciale détournée ou un défaut propre à votre activité peut ne figurer dans aucune ligne de la liste.
Une liste datée
Les rangs et les intitulés évoluent d'une édition à l'autre. Un document qui cite le Top 10 sans en préciser l'année est difficile à interpréter.
Applications concrètes
À quoi il sert, concrètement.
Six usages où une liste commune de risques fait gagner du temps, de la commande d'une application jusqu'à la lecture d'un rapport.
Organiser un audit par familles de risques
Répartir les contrôles et les constats selon les catégories pertinentes pour l'application, pour que rien d'important ne soit oublié et que le rapport reste lisible.
Écrire un cahier des charges sécurité
Nommer les risques que le prestataire doit traiter, avec des intitulés que la direction et les développeurs comprennent de la même façon.
Sensibiliser une équipe de développement
Offrir une porte d'entrée reconnue pour une première formation, avant d'aborder des référentiels de vérification plus détaillés.
Reprendre une application d'un autre prestataire
Passer en revue les familles de risques les plus courantes pour se faire une première idée de l'état de l'application, avant une analyse approfondie.
Préparer la conception d'une nouvelle application
S'appuyer sur les catégories pour questionner le plan avant l'écriture du code, là où une correction coûte le moins.
Expliquer un rapport à la direction
Relier chaque constat technique à une famille de risques connue, pour décider des priorités et des budgets en connaissance de cause.
Le référentiel en un coup d'œil
Les dix catégories de l'édition 2025.
Chaque catégorie, avec ce qu'elle signifie pour une entreprise. Les intitulés officiels sont en anglais ; nous en donnons ici une traduction courte.
- A01
Contrôle d'accès défaillant
Un utilisateur voit ou modifie ce qui ne le concerne pas : le dossier d'un autre client, une fonction d'administration. Les requêtes forgées côté serveur (SSRF) y ont été rattachées en 2025.
- A02
Mauvaise configuration de sécurité
Le logiciel est sain, son paramétrage ne l'est pas : réglage laissé par défaut, service ouvert par erreur, message d'erreur trop bavard.
- A03
Failles de la chaîne logicielle
Votre application repose sur des bibliothèques, des outils de construction et des services tiers. Si l'un d'eux est compromis ou périmé, vous en héritez.
- A04
Défauts de cryptographie
Des données sensibles insuffisamment protégées, en circulation ou au repos : chiffrement absent, dépassé ou mal employé.
- A05
Injection
L'application exécute comme une instruction ce qui n'aurait dû être qu'une donnée saisie : requête de base de données, commande système, script glissé dans une page.
- A06
Conception non sécurisée
La faille est dans le plan et non dans le code : une règle métier qui se laisse détourner, par exemple. Aucune correction ligne à ligne n'y suffit.
- A07
Défaillances d'authentification
Quelqu'un se fait passer pour un autre : mots de passe faibles, sessions mal protégées, récupération de compte trop permissive.
- A08
Intégrité des logiciels et des données
Rien ne prouve que le code ou les données reçus sont ceux qui étaient attendus : mise à jour non vérifiée, données altérées en route.
- A09
Journalisation et alertes insuffisantes
Une attaque est en cours et personne ne la voit : événements non enregistrés, ou enregistrés sans que quiconque soit prévenu.
- A10
Mauvaise gestion des conditions exceptionnelles
Catégorie nouvelle en 2025. Quand quelque chose tourne mal, le système doit refuser l'accès, pas l'accorder : une panne ne doit jamais ouvrir une porte.
Source : OWASP Top 10:2025. Traduction et explications rédigées par nos soins ; seuls les intitulés anglais font foi.
Faire le bon choix
Le Top 10 : utile, mais pour quoi faire ?
Un bon outil se reconnaît à ses limites. Voici les situations où le Top 10 rend service, et celles où il faut s'appuyer sur autre chose.
Elle convient quand
- Vous devez expliquer à une direction, à un client ou à un assureur les grandes familles de risques d'une application, avec des mots que tous comprennent.
- Vous rédigez un cahier des charges et voulez y inscrire des exigences de sécurité lisibles, sans rédiger un référentiel entier.
- Vous souhaitez ordonner les constats d'un audit ou d'un test d'intrusion pour suivre les corrections famille par famille.
- Vous formez une équipe de développement et cherchez un point d'entrée reconnu, avant d'aller vers des exigences plus fines.
Il vaut mieux l'éviter, ou la compléter, quand
- Un client, un appel d'offres ou un régulateur impose une conformité : le Top 10 n'est pas une norme, et il faut identifier l'exigence réellement demandée.
- Vous attendez une liste de vérifications exhaustive à cocher : dix catégories ne suffisent pas à contrôler une application, et le document lui-même le rappelle.
- Votre risque principal tient à une règle propre à votre activité (remises, validations, droits d'un métier) : seul un examen de cette logique en rendra compte.
- On vous promet une application « couverte à 100 % » : OWASP déconseille lui-même ce type d'affirmation, car elle ne peut pas être exacte.
Le parcours, étape par étape
Comment nous nous en servons dans un audit.
Le Top 10 sert de grille de lecture, pas de liste de contrôle. Il organise notre travail sans le limiter à ce qu'il décrit.
Cartographier
Fonctions, rôles, données manipulées, dépendances et services tiers : on décrit l'application avant de la juger.
Choisir les familles
Nous retenons les catégories qui concernent réellement votre architecture et en déduisons le plan de contrôle.
Examiner en profondeur
Droits d'accès, saisies, configuration, dépendances : les contrôles vont plus loin que l'intitulé de la catégorie.
Classer et expliquer
Chaque constat est rattaché à sa famille de risques et placé dans l'ordre de priorité, avec l'édition de référence indiquée.
Vérifier les corrections
Une fois les correctifs posés, nous contrôlons que le défaut a bien disparu et qu'aucun autre n'a été introduit.
Une démarche de lecture, non une conformité : le Top 10 ne remplace ni l'examen de votre logique métier ni les exigences propres à votre secteur.
Notre façon de l'intégrer
Comment nous l'intégrons.
Une approche en quatre temps, pour que le Top 10 reste un outil de lecture et ne devienne pas un argument commercial.
Poser le cadre avec vous
Nous précisons ce que vous attendez : comprendre un risque, préparer un appel d'offres, suivre des corrections. Le Top 10 n'est retenu que s'il répond à ce besoin.
Adapter la lecture à votre application
Un site vitrine, une plateforme connectée et une API n'exposent pas les mêmes familles de risques. Nous retenons celles qui comptent pour votre architecture.
Restituer par famille et par priorité
Les constats sont présentés avec leur catégorie, l'édition citée et un ordre d'urgence. Vous pouvez en déduire un plan d'action sans lire une ligne de code.
Prolonger par les bonnes pratiques
Quand un constat appelle une mesure durable (configuration, droits, suivi des dépendances), nous la rattachons à la démarche de maintenance plutôt qu'à une correction ponctuelle.
Aller plus loin
De la technologie au projet.
La technologie se choisit après le besoin : voici les expertises qui portent le projet, et les technologies voisines à comparer.
Expertises métier
- Audit de sécurité des applications webLa démarche de contrôle, de la revue de code au test d'intrusion, avec des constats classés par priorité.
- Sécurisation des applications et APILes protections à mettre en place côté application pour réduire les familles de risques les plus courantes.
- Authentification et gestion des accèsDroits, sessions et identités, au cœur des catégories sur le contrôle d'accès et l'authentification.
- Maintenance et suivi de sécuritéMises à jour, dépendances et surveillance dans la durée, pour la chaîne logicielle et la configuration.
- Protection des donnéesChiffrement, sauvegardes et maîtrise des données sensibles, en lien avec les défauts de cryptographie.
Technologies voisines
Toutes les technologies du pôle
Questions fréquentes
Les questions qu'on nous pose sur le Top 10.
Des réponses courtes, pour lire une mention de l'OWASP sans se tromper de promesse.
Sources
Fiche relue en novembre 2026.
Peut-on dire qu'un site est conforme à l'OWASP Top 10 ?
Non. Le Top 10 est un document de sensibilisation, pas une norme : il ne définit pas de critères de conformité à atteindre. OWASP décourage d'ailleurs toute affirmation de couverture complète de la liste. Nous l'utilisons comme cadre de lecture de nos audits et nous ne présentons pas un résultat comme une conformité au Top 10.
Quelle différence entre le Top 10 et l'ASVS ?
Le Top 10 sensibilise à dix familles de risques. L'ASVS (Application Security Verification Standard) est une liste d'exigences de sécurité vérifiables, utilisable pour concevoir, tester ou rédiger un contrat. Le Top 10 lui-même recommande l'ASVS dès qu'on cherche un standard à appliquer. Voir aussi notre démarche de sécurisation des applications et des API.
Qu'est-ce qui change dans l'édition 2025 ?
La catégorie sur la chaîne d'approvisionnement logicielle élargit l'ancienne catégorie des composants vulnérables ou obsolètes. Celle sur la mauvaise gestion des conditions exceptionnelles est entièrement nouvelle. Les requêtes forgées côté serveur (SSRF) sont rattachées au contrôle d'accès, et la mauvaise configuration passe du cinquième au deuxième rang.
Un site vitrine ou un site WordPress est-il concerné ?
Oui, même sans espace client ni paiement. Une extension non mise à jour relève de la chaîne logicielle, un compte d'administration faible de l'authentification, un réglage laissé par défaut de la configuration. Les catégories qui comptent diffèrent d'un site à l'autre, d'où l'intérêt de les choisir avant d'examiner. Un suivi régulier est décrit dans notre maintenance et suivi de sécurité.
L'édition 2021 est-elle encore valable dans un contrat ?
Une mention de 2021 reste compréhensible : la plupart des catégories se retrouvent d'une édition à l'autre. Mais l'édition 2025 déplace des rangs et en crée une nouvelle. Dans un contrat ou un rapport, précisez l'année visée ; nous indiquons l'édition de référence. Côté navigateur, une autre couche de protection existe : voir la fiche sur la politique de sécurité des contenus et les en-têtes de sécurité.
Une mention de l'OWASP dans un devis ou un rapport ?
Montrez-nous le document : nous vous disons ce qu'il prouve, ce qu'il ne prouve pas, et ce qu'il reste à vérifier sur votre application.