OWASP Top 10:2025 pour les dirigeants : dix risques, dix questions à votre équipe

Ce qu’est l’OWASP Top 10, et ce qu’il n’est pas

L’Open Worldwide Application Security Project (OWASP) est une fondation à but non lucratif. Sa publication la plus connue est l’OWASP Top 10 : la liste des dix principaux risques de sécurité des applications web. Elle s’appuie sur des données de tests fournies par des entreprises et des auditeurs, et sur une enquête menée auprès de professionnels.

L’OWASP présente elle-même la liste comme un document de sensibilisation. Elle doit montrer aux développeurs, aux architectes et aux dirigeants où se situent les risques majeurs. Ce qu’elle n’est pas :

• Pas une certification. Il n’existe ni label OWASP ni conformité OWASP. Si quelqu’un vous en vend une, il vous vend autre chose.
• Pas un référentiel de contrôle complet. Pour des exigences détaillées, il existe l’OWASP Application Security Verification Standard (ASVS).
• Pas une loi. Mais une référence largement reconnue de ce que signifie « l’état de l’art » pour une application web.

Pour un dirigeant, la liste reste précieuse : en dix points, elle montre où les applications sont le plus souvent et le plus gravement vulnérables. Et elle vous donne un langage commun avec votre équipe et vos prestataires.

Ce qui change en 2025

L’édition 2025 remplace la version de 2021. Selon l’OWASP, elle compte deux nouvelles catégories et un regroupement :

• Nouveau : les défaillances de la chaîne d’approvisionnement logicielle (A03). Elle élargit l’ancienne catégorie « composants vulnérables et obsolètes » à tout ce qui peut mal tourner entre les dépendances, les systèmes de build et la distribution. Les professionnels interrogés l’ont plébiscitée.
• Nouveau : la mauvaise gestion des situations exceptionnelles (A10). Gestion des erreurs, erreurs de logique et systèmes qui restent « ouverts » au lieu de se « fermer » en cas de panne.
• Regroupé : la falsification de requête côté serveur (SSRF), catégorie à part entière en 2021, fait désormais partie du contrôle d’accès défaillant (A01).
• En hausse : la mauvaise configuration de sécurité passe de la cinquième à la deuxième place. Une part croissante du comportement d’une application dépend de sa configuration plutôt que de son code.

La base d’analyse s’est élargie : l’OWASP a étudié 589 types de faiblesses (CWE), contre près de 400 en 2021. Huit catégories sont issues des données, deux de l’enquête, car certains risques apparaissent à peine dans les données de tests.

Les dix risques en bref

Pour chaque risque, vous trouverez trois éléments : ce que c’est, ce qu’il peut coûter à votre entreprise, et la question à poser à votre équipe. Tous les exemples sont fictifs.

A01 : contrôle d’accès défaillant

Ce que c’est : des utilisateurs peuvent voir des données ou effectuer des actions pour lesquelles ils n’ont pas de droits.

Ce que cela coûte (exemple fictif) : un espace client affiche les factures sous un numéro séquentiel. Un client modifie le chiffre dans la barre d’adresse et voit les factures d’autres clients. S’ensuivent une notification à la CNIL, un courrier à toutes les personnes concernées et un grand compte qui réexamine son contrat.

La question à votre équipe : « Notre serveur vérifie-t-il à chaque accès que cet utilisateur a le droit de voir précisément cet enregistrement, ou comptons-nous sur le fait que personne ne modifie l’adresse ? »

A02 : mauvaise configuration de sécurité

Ce que c’est : paramètres par défaut non sécurisés, interfaces d’administration exposées, messages d’erreur trop bavards ou protections absentes au niveau du serveur, du framework ou du cloud.

Ce que cela coûte (exemple fictif) : un espace de stockage contenant des sauvegardes est lisible publiquement par erreur. Personne ne s’en aperçoit avant qu’un chercheur en sécurité ne vous contacte. Impossible de savoir si quelqu’un d’autre a téléchargé les données avant lui.

La question à votre équipe : « Qui vérifie que notre configuration de production est aussi sûre que prévu, et à quelle fréquence ? »

A03 : défaillances de la chaîne d’approvisionnement logicielle

Ce que c’est : des vulnérabilités ou du code malveillant qui entrent dans votre logiciel par des bibliothèques, des outils, des systèmes de build ou des mises à jour.

Ce que cela coûte (exemple fictif) : un paquet open source populaire reçoit une mise à jour piégée. Votre chaîne de build la récupère automatiquement, et quelques jours plus tard votre application distribue du code malveillant à vos propres clients.

La question à votre équipe : « Savons-nous quels composants, dans quelle version, se trouvent dans notre logiciel, et comment apprenons-nous l’existence d’une nouvelle faille ? »

A04 : défaillances cryptographiques

Ce que c’est : des données sensibles ne sont pas chiffrées, le sont mal ou avec des méthodes obsolètes, ou les clés ne sont pas protégées.

Ce que cela coûte (exemple fictif) : les mots de passe sont stockés avec une méthode dépassée. Après une fuite, ils sont lisibles en clair en peu de temps, et comme beaucoup d’utilisateurs réutilisent leurs mots de passe, le préjudice s’étend à d’autres services.

La question à votre équipe : « Quelles données sensibles stockons-nous, comment sont-elles chiffrées et où se trouvent les clés ? »

A05 : injection

Ce que c’est : une saisie de l’utilisateur est exécutée comme une commande, par exemple comme requête en base de données ou comme script dans le navigateur d’autres utilisateurs.

Ce que cela coûte (exemple fictif) : le champ de recherche d’une boutique en ligne insère la saisie directement dans une requête SQL. Un attaquant en extrait toute la table clients, adresses et historique de commandes compris.

La question à votre équipe : « Utilisons-nous partout des requêtes paramétrées et un encodage cohérent des sorties, ou existe-t-il des endroits où les saisies sont transmises telles quelles ? »

A06 : conception non sécurisée

Ce que c’est : la faiblesse ne se trouve pas dans une ligne de code, mais dans le concept : un processus n’a jamais été pensé face aux abus.

Ce que cela coûte (exemple fictif) : un système de bons d’achat vérifie chaque code, mais ne limite pas le nombre d’essais par compte. Un script trouve des centaines de bons valides en une nuit.

La question à votre équipe : « Avons-nous réfléchi à la manière dont nos processus clés pourraient être détournés, et l’avons-nous documenté ? »

A07 : défaillances d’authentification

Ce que c’est : des faiblesses à la connexion et dans les sessions : règles de mot de passe faibles, absence de protection contre les essais en masse, sessions qui n’expirent jamais.

Ce que cela coûte (exemple fictif) : des attaquants testent automatiquement sur votre page de connexion des identifiants issus de fuites d’autres sites. Faute de limite au nombre d’essais, ils prennent le contrôle de dizaines de comptes clients et passent commande à leurs frais.

La question à votre équipe : « Que se passe-t-il si quelqu’un tente de se connecter mille fois par minute, et proposons-nous l’authentification à deux facteurs ? »

A08 : défaillances d’intégrité du logiciel ou des données

Ce que c’est : l’application fait confiance à du code, des mises à jour ou des données sans vérifier qu’ils sont intacts et proviennent d’une source fiable.

Ce que cela coûte (exemple fictif) : le site intègre un script hébergé sur un serveur tiers. Ce serveur est compromis, et le script capte désormais les données de paiement saisies dans le formulaire de commande.

La question à votre équipe : « Vérifions-nous que les mises à jour, les scripts et les données externes n’ont pas été altérés avant de les utiliser ? »

A09 : défaillances de journalisation et d’alerte de sécurité

Ce que c’est : les événements de sécurité ne sont pas journalisés, ou personne ne les regarde parce qu’aucune alerte n’est déclenchée.

Ce que cela coûte (exemple fictif) : pendant des semaines, un attaquant teste des comptes. Les journaux le montrent, mais personne n’est prévenu. Vous découvrez l’incident quand un client appelle, et le délai pour le notifier à l’autorité est déjà serré.

La question à votre équipe : « À quoi reconnaîtrions-nous une attaque en cours, et qui serait prévenu, en combien de temps ? »

A10 : mauvaise gestion des situations exceptionnelles

Ce que c’est : l’application réagit mal à l’imprévu : erreurs ignorées, contrôles sautés ou détails internes divulgués.

Ce que cela coûte (exemple fictif) : quand le service de contrôle des droits tombe brièvement en panne, l’application laisse passer toutes les requêtes par défaut. Pendant quelques minutes, chaque utilisateur est administrateur.

La question à votre équipe : « Que fait notre application quand un service, une base de données ou un contrôle tombe en panne : elle bloque ou elle laisse passer ? »

Comment interpréter les réponses de votre équipe

Inutile de maîtriser les détails techniques pour distinguer une bonne réponse d’une réponse faible. Trois repères vous aident :

• Une bonne réponse est concrète. « Chaque requête passe par notre module de droits, et des tests vérifient que l’utilisateur A ne voit pas les données de B » est une bonne réponse. « Le framework s’en charge » est un espoir.
• Une bonne réponse décrit un processus. Une équipe qui fait vérifier automatiquement ses dépendances, applique les mises à jour régulièrement et sait qui décide en cas d’urgence a un processus. « On met à jour quand il y a un problème » n’en est pas un.
• Une bonne réponse connaît ses limites. Une équipe qui répond « Nous ne l’avons jamais vérifié » est honnête, et c’est un bon point de départ. Méfiance en revanche si chaque question reçoit la réponse « Ce n’est pas un sujet chez nous ».

Soyez particulièrement attentif au code repris, par exemple d’une agence ou après une acquisition, et au code écrit en grande partie avec des assistants IA. Dans les deux cas, personne dans l’équipe ne connaît souvent chaque partie en détail. Les dix questions montrent vite où le savoir manque.

Encore un point : ces questions ne sont pas un vote de défiance envers votre équipe. Les bons développeurs apprécient qu’une direction prenne la sécurité au sérieux, car ils obtiennent alors du temps et du budget pour s’en occuper. Posez donc les questions ouvertement, pas comme un examen. Consignez les réponses par écrit : elles serviront de point de départ à tout audit ultérieur et montreront dans un an ce qui s’est amélioré.

Quel contrôle trouve quel risque

Aucun contrôle ne couvre à lui seul les dix risques. Le tableau montre honnêtement ce que voit chacune de nos offres. Certains risques n’apparaissent que lors d’une revue de code ou d’architecture.

En grande partie : les schémas typiques de la catégorie sont vérifiés. En partie : seuls certains aspects sont visibles. Aucune vérification ne détecte toutes les failles d’une catégorie.

Quelques précisions :

• Le test de sécurité ne voit que ce que voit n’importe quel navigateur : chiffrement, en-têtes de sécurité, cookies, fichiers exposés et versions visibles. Un bon premier regard, qui s’arrête toutefois à la page de connexion.
• L’audit d’application vérifie avec deux comptes de test si l’utilisateur A voit les données de l’utilisateur B, si les sessions sont sûres et si les saisies et les interfaces sont attaquables.
• L’audit de code trouve des causes invisibles depuis l’extérieur : dépendances présentant des failles connues, clés dans le code, contrôles manquants dans des chemins rarement utilisés.
• La conception non sécurisée et l’alerte ne se lisent qu’en partie dans le code. Savoir si un processus peut être détourné et si quelqu’un réagit à une alerte en pleine nuit relève d’un échange sur l’architecture et l’exploitation. Pour les grandes organisations, nous proposons pour cela une revue d’architecture de sécurité.

L’audit complet combine audit d’application et audit de code : les constats peuvent se confirmer mutuellement, et un expert valide chacun d’eux. Notre façon de procéder est décrite dans notre méthodologie.

Où s’arrête un audit de code et où commence un test d’intrusion, notre comparatif audit de code ou test d’intrusion vous le montre.

OWASP, NIS2, CRA et RGPD

Aucune loi n’impose l’OWASP Top 10. Plusieurs textes exigent en revanche une sécurité conforme à l’état de l’art, et le Top 10 en est une référence largement utilisée :

• La directive NIS2 prévoit que les entités concernées prennent des mesures de gestion des risques, y compris la sécurité du développement et de la maintenance des systèmes et le traitement des vulnérabilités. En France, sa transposition (projet de loi relatif à la résilience) est encore en cours d’examen au Parlement en novembre 2026. En Allemagne (§ 30 BSIG), ces obligations s’appliquent depuis le 6 décembre 2025.
• Le Cyber Resilience Act (CRA) impose aux fabricants de produits comportant des éléments numériques de les mettre sur le marché sans vulnérabilité exploitable connue à partir du 11 décembre 2027 et de gérer les vulnérabilités tout au long du cycle de vie. Les obligations de signalement s’appliquent déjà depuis le 11 septembre 2026 ; pour en savoir plus, lisez notre article sur le signalement au titre du Cyber Resilience Act.
• L’article 32 du RGPD, dont la CNIL contrôle l’application en France, exige des mesures techniques et organisationnelles appropriées et une procédure pour en tester régulièrement l’efficacité.

Un audit selon l’OWASP Top 10 n’est ni un certificat ni une évaluation de conformité. Il documente en revanche que vous avez vérifié votre application selon une référence reconnue et priorisé les constats. D’après notre expérience, c’est ce que demandent de plus en plus souvent clients, auditeurs et assureurs.

Trois actions pour cette semaine

1. Obtenir le regard extérieur. Faites vérifier votre site ou votre application web la plus importante avec notre test de sécurité gratuit. Vous recevez en général sous 2 heures (jours ouvrés) une note de A à F et les constats classés par gravité.
2. Poser trois questions. Emportez les questions sur A01, A02 et A03 dans votre prochain échange avec votre équipe ou votre agence. Si les réponses hésitent, vous savez par où commencer.
3. Choisir la profondeur d’analyse. Pour une application avec connexion, nous recommandons l’audit d’application à 490 € HT ; pour votre propre code ou un code repris, l’audit de code à 890 € HT. Les deux réunis, avec validation de chaque constat par un expert, forment l’audit complet à 1 690 € HT.

Tous les prix s’entendent HT, TVA en sus. Nos offres sont réservées aux professionnels.

La première étape ne coûte rien

Le test de sécurité est gratuit et passif : nous n’attaquons rien et n’avons pas besoin de connexion. Il vous montre lesquels des dix risques sont déjà visibles depuis l’extérieur, puis nous vous disons franchement si un audit vaut la peine pour vous, et lequel.

Ce que coûte un audit et comment comparer les devis : lisez combien coûte un audit de code ?

OWASP® est une marque déposée de l’OWASP Foundation. Nous n’avons aucun lien avec l’OWASP Foundation, qui ne recommande ni ne certifie nos prestations.

Cet article a été rédigé avec l’aide de recherches automatisées et de l’IA. David Kreutzer l’a relu et validé le 4 novembre 2026.