Normes et standards / Référentiel OWASP · édition 2025
L'Open Web Application Security Project (OWASP) recense les 10 familles de failles les plus fréquentes sur les projets web. C'est un document de sensibilisation, publié librement, et la référence la plus citée du domaine : il dit où regarder en premier, pas ce qu'il faut vérifier ligne à ligne.
C'est pour cela que nous l'utilisons, et pour le vocabulaire commun qu'il donne à une discussion avec un client. Cette page détaille chaque risque : ce qu'il donne concrètement sur une application métier, ce que nous faisons pour l'éviter et ce qui permet de le vérifier.
POURQUOI L'OWASP TOP 10
Des référentiels bien plus exhaustifs existent. C'est pourtant celui-là que nous ouvrons en premier, pour ces trois raisons.
Mettre des mots précis sur les risques sans se perdre dans le jargon. On remplace le mot fourre-tout « faille » par le vrai sujet, un contrôle d'accès défaillant par exemple, et on priorise calmement ce qui compte.
Ce classement s'appuie sur des millions d'applications réelles et sur les vulnérabilités réellement publiées. On ne travaille pas sur des scénarios catastrophe théoriques, mais sur ce qui touche concrètement la production.
Personne n'ouvre un catalogue d'exigences d'ingénierie au premier atelier d'un projet. Le Top 10 se lit sans être spécialiste et fixe le cap ; l'ASVS, publié par la même fondation, prend le relais au moment de vérifier, exigence par exigence.
Vue d'ensemble · édition 2025
L'ordre est celui du classement officiel : il traduit la fréquence observée, pas la gravité.
| Identifiant | Risque | Explication |
|---|---|---|
| A01:2025 | Contrôle d'accès défaillant Broken Access Control | Accéder à des données ou exécuter des actions sans en avoir le droit. |
| A02:2025 | Mauvaise configuration de sécurité Security Misconfiguration | Le code est irréprochable, mais l'environnement laisse une porte ouverte. |
| A03:2025 | Défaillances de la chaîne d'approvisionnement logicielle Software Supply Chain Failures | La faille s'infiltre par une dépendance ou le processus de build. |
| A04:2025 | Défaillances cryptographiques Cryptographic Failures | Exposer des données sensibles en transit ou stockées sans protection suffisante. |
| A05:2025 | Injection Injection | Transformer une simple saisie utilisateur en instruction exécutable. |
| A06:2025 | Conception non sécurisée Insecure Design | Une fonctionnalité bancale dès sa conception, indépendamment du code. |
| A07:2025 | Défaillances d'authentification Authentication Failures | Vérifier la véritable identité d'un utilisateur et gérer ses sessions. |
| A08:2025 | Défauts d'intégrité des logiciels et des données Software or Data Integrity Failures | Injecter du code ou des données non vérifiés au cœur de l'application. |
| A09:2025 | Défaillances de journalisation et d'alerte Security Logging and Alerting Failures | L'incident se produit sans que personne n'en soit averti. |
| A10:2025 | Mauvaise gestion des conditions exceptionnelles Mishandling of Exceptional Conditions | Une erreur ou un cas limite ouvre une brèche au lieu de bloquer. |
Important à comprendre
Confondre sensibilisation et contrôle d'ingénierie est l'erreur la plus coûteuse en sécurité applicative.
L'OWASP Top 10 sert à prioriser, pas à valider. Il classe des familles de risques pour savoir où regarder en premier, mais n'offre aucune garantie d'exhaustivité. Se croire protégé parce qu'on a « coché les dix cases » est un piège : plusieurs de ces risques ne se détectent par aucun outil automatique, ni depuis l'extérieur.
Pour valider la sécurité d'un code, le vrai référentiel s'appelle l'ASVS (publié par la même fondation). Il aligne des centaines d'exigences concrètes et mesurables. En clair : le Top 10 fixe le cap, l'ASVS fournit la liste de contrôle.
Dernier piège : les identifiants bougent. Un code comme « A03 » ne désigne pas la même faille entre l'édition 2021 et l'édition 2025. Citer une catégorie sans préciser son année d'édition rend n'importe quel rapport ou cahier des charges immédiatement ambigu.
Comment ce classement est établi
Cette édition s'appuie sur l'analyse de 2,8 millions d'applications et de 175 000 CVE rattachées à des CWE. Huit catégories découlent directement de ces données brutes. Deux autres viennent d'un vote de la communauté, pour couvrir les risques que la donnée seule ne capte pas : A03 Software Supply Chain Failures, peu présente dans les données mais désignée comme préoccupation majeure par les praticiens, et A09 Security Logging and Alerting Failures, sous-représentée parce qu'elle ne se teste pratiquement pas de façon automatisée.
Quand une catégorie recule dans le classement, le risque ne disparaît pas pour autant. Cela indique surtout qu'on la croise moins en production, souvent parce que les frameworks modernes la corrigent désormais par défaut.
Les dix risques · édition 2025
Version SmartBooster simplifiée de la documentation officielle. Le classement reflète la fréquence constatée sur le terrain, pas nécessairement la gravité du risque.
A01:2025 · Broken Access Control
L'application ne valide pas strictement qui a le droit de faire quoi. C'est le risque le plus répandu en production, indétrônable en première place du classement.
Changer un ID dans l'URL /devis/4213 ouvre le document du voisin. Un rôle lecture seule accède à la suppression parce que le bouton est simplement masqué en CSS. Depuis 2025, cette catégorie englobe aussi le SSRF : forcer votre serveur à interroger le réseau interne pour le compte d'un attaquant.
Les règles d'accès se rédigent avant la première ligne de code : quels profils d'utilisateur existent, ce que chacun atteint par route, et à quel sous-ensemble de données il a droit. Cette documentation est publiée dans le logiciel lui-même, là où elle se relit, plutôt que dans un document annexe que personne ne rouvre.
Le tableau des droits ne se tient pas à la main : il est généré à partir des rôles de sécurité déclarés dans Symfony. Ce qui est publié dans l'application décrit donc l'état réel du code, et ne peut pas diverger de lui au fil des évolutions.
Les droits d'accès sont portés par le composant Security de Symfony, côté serveur, jamais par du code front : masquer un bouton n'est pas un contrôle. Refus par défaut, et contrôle rejoué à chaque requête, y compris sur les appels d'API que déclenche l'interface.
Les tests fonctionnels rejouent les parcours avec un utilisateur non autorisé et attendent un refus : le crawler couvre les droits attachés aux routes. Les sous-ensembles de données se vérifient au niveau des requêtes en base, sur un jeu de données maîtrisé que DAMA réinitialise à chaque test. Aucun scan ne devine quel utilisateur a le droit de voir quel devis : l'effort reste sur la conception et les tests.
A02:2025 · Security Misconfiguration
Le problème ne vient pas de la logique applicative, mais du paramétrage des serveurs et des services. Cette catégorie bondit à la deuxième place en 2025.
Le mode debug oublié en production qui expose les variables d'environnement. Une console d'administration accessible sans restriction d'accès. Des en-têtes HTTP de sécurité absents ou les mots de passe par défaut de l'infrastructure qui ne sont jamais changés.
Les variables d'environnement sont déclarées au niveau de l'hébergement, chez Clever Cloud, et ne sont jamais commitées dans le dépôt. Le reste de la configuration vit dans le code et se déploie avec lui : nous n'administrons pas le serveur Apache, les en-têtes HTTP de sécurité et la politique de contenu sont donc posés par l'application ou par un .htaccess versionné. Les environnements passent par la même pipeline, ce qui supprime le réglage manuel qui diverge.
C'est la catégorie de prédilection du scan dynamique : en-têtes manquants, cookies mal configurés, partage de ressources trop permissif, pages d'erreur bavardes se détectent depuis l'extérieur, sans accès au code. Nous passons ces contrôles avec OWASP ZAP en boîte noire, sur l'application déployée.
A03:2025 · Software Supply Chain Failures
Votre code interne est propre, mais vos dépendances ou vos outils de livraison sont compromis. L'édition 2025 élargit ce sujet historique aux pipelines CI/CD.
Une bibliothèque abandonnée dont la faille est publique. Un paquet piraté sur le registre officiel. Une image Docker basée sur un OS ou une dépendance vulnérable. Un jeton CI/CD qui traîne dans une variable de pipeline ou fuite dans les logs de build.
Les versions installées sont figées par les fichiers de verrouillage, composer.lock et package-lock.json, commités avec le code : deux déploiements successifs installent exactement les mêmes paquets. Une librairie abandonnée est remplacée avant l'incident, pas après.
Les montées de version se planifient au fil de l'eau, pas le jour où une faille est publiée. C'est ce qui rend un correctif de sécurité applicable : sur une dépendance encore sous support actif, il s'intègre en une montée mineure ; sur une version abandonnée depuis deux ans, il suppose une migration que personne n'a budgétée.
composer audit, npm audit et osv-scanner tournent à chaque intégration, et repassent sur des scans planifiés : une faille publiée après le dernier commit se signale sans attendre la prochaine livraison. La correction, elle, s'automatiserait en théorie : rien n'empêche techniquement un robot d'appliquer la montée de version et de la livrer. Nous ne le faisons pas, parce qu'une mise en production n'est jamais anodine et que nous préférons la voir décidée et menée par quelqu'un qui en mesure les effets.
A04:2025 · Cryptographic Failures
Protéger faiblement ce qui devrait être strictement illisible. La catégorie reculant à la quatrième place traduit les progrès natifs des frameworks.
Mots de passe hachés avec des algorithmes dépassés. Exports clients déposés en clair sur un espace de fichiers. Échanges API qui transitent en HTTP ou des clés de chiffrement commitées dans Git.
Le hachage est confié au composant du framework plutôt qu'écrit à la main. HTTPS est imposé partout, y compris entre nos propres services. Les secrets sont tenus hors du dépôt et rendus par l'hébergement.
Partiellement. Un scan voit un flux non chiffré et un protocole faible ; il ne voit pas comment un mot de passe est stocké en base. Cette moitié-là se vérifie par un standard interne posé en amont, puis par revue de code.
A05:2025 · Injection
Passer des données non nettoyées directement à un interpréteur sans contrôles. Autrefois reine des failles, l'injection chute au cinquième rang grâce notamment à la généralisation des ORM et aux outils d'analyse de code.
Concaténer un champ texte dans une requête SQL. Laisser un script s'exécuter dans un commentaire réaffiché (XSS). Passer une saisie brute à une commande système côté serveur.
Requêtes préparées par l'ORM, échappement par défaut du moteur de rendu côté serveur comme côté front, validation des entrées au niveau du formulaire. L'essentiel du travail est fait par des outils qui échappent par défaut, ce qui explique en grande partie ce recul.
Terrain historique du scan actif, qui envoie de vraies charges et déduit le problème de la réaction obtenue. L'analyse de teinte de Psalm le complète depuis l'intérieur : elle suit une saisie utilisateur jusqu'au point où elle est exécutée, et signale le chemin quand rien ne l'a assainie en route. C'est le complément de PHPStan, qui vérifie les types mais ne suit pas le trajet d'une donnée.
A06:2025 · Insecure Design
L'erreur se situe dans la logique métier adoptée. Aucun correctif rapide ne la règle : il faut repenser le fonctionnement de la fonctionnalité.
Un formulaire de mot de passe oublié sans limitation de tentatives. Un prix calculé dans le navigateur puis renvoyé au serveur. Un export autorisant l'aspiration de la base en une seule requête.
Les besoins qui reviennent d'un projet à l'autre, authentification, gestion des droits, imports et exports, s'appuient sur des briques déjà éprouvées que chaque projet améliore. Repartir d'une page blanche à chaque fois, c'est refaire les erreurs de conception que quelqu'un a déjà corrigées ailleurs.
Chaque dépendance ajoutée est du code que nous n'avons pas écrit et que nous devons pourtant comprendre, suivre et mettre à jour. Nous en limitons le nombre volontairement : un périmètre restreint est un périmètre maîtrisé, sur lequel une alerte de sécurité se traite sans découvrir le composant le jour de l'incident.
Les décisions prises et les analyses qui y ont conduit sont écrites et conservées, projet après projet. Une question déjà tranchée ne se re-débat pas, et la conception s'améliore sur la durée au lieu de dépendre de qui se trouve dans la salle ce jour-là.
Rien d'automatique. C'est le risque où aucun outil ne remplace la revue et l'expérience, et celui qui justifie un test d'intrusion mené par des humains quand l'enjeu le mérite. Ce qui le rend vérifiable chez nous, c'est notre workflow de ticket, qui impose une validation de la conception avant tout développement, et la documentation fonctionnelle et technique centralisée dans le code : elle suit l'état réel du projet et reste visible de tous les intervenants.
A07:2025 · Authentication Failures
L'application ne s'assure pas correctement que l'utilisateur est bien celui qu'il prétend être. L'édition 2025 a resserré l'intitulé sur la seule authentification.
L'absence de rate-limiting qui permet les attaques par force brute. Une session qui n'expire jamais. Des liens de connexion envoyé par email et valides indéfiniment ou l'absence de MFA sur les comptes d'administration.
L'authentification est confiée au composant du framework, avec limitation de fréquence sur les points d'entrée, jetons à usage unique et à durée courte, et second facteur sur les rôles sensibles quand le contexte le justifie. Ce code est centralisé dans un bundle interne réutilisé sur tous nos projets : c'est une pièce trop centrale pour être réécrite à chaque fois, et chaque durcissement bénéficie à l'ensemble.
Partiellement. Un scan détecte l'absence de limitation et une session dont la durée est excessive. Il ne juge pas la politique d'accès elle-même, qui relève d'un arbitrage avec vous.
A08:2025 · Software or Data Integrity Failures
Faire confiance aveuglément à des sources de données, du code ou des mises à jour sans contrôler leur provenance ou leur signature.
Une dépendance récupérée sans vérification d'intégrité. Un script tiers chargé depuis un domaine externe dans une page. Des données désérialisées telles qu'elles ont été reçues. Un déploiement fait à la main depuis un poste de développeur.
Le déploiement passe exclusivement par la pipeline sur Gitlab, depuis une branche protégée : personne ne livre en se connectant au serveur. Les fichiers de verrouillage sont commités, et les scripts tiers autorisés sont déclarés dans la politique de contenu.
En partie par le scan, pour les ressources externes que chargent les pages. En partie par la configuration de la pipeline. Un déploiement manuel impossible se vérifie surtout par le fait qu'aucun autre chemin n'existe.
A09:2025 · Security Logging and Alerting Failures
Subir une attaque sans rien voir venir. L'édition 2025 insiste : logger des événements est inutile si personne n'est immédiatement alerté.
Des échecs de connexion répétés qui ne laissent aucune trace. Une erreur en production découverte parce qu'un utilisateur a téléphoné. Des journaux conservés quelques heures seulement, rendant toute enquête post-mortem impossible.
Les erreurs applicatives sont remontées avec leur pile d'exécution dans Sentry, dont les alertes préviennent l'équipe sans attendre qu'un utilisateur nous contacte. La disponibilité est mesurée en continu et les métriques de disponibilités conservées pendant 90 jours. Les journaux ne contiennent ni mot de passe ni jeton.
Les entités sensibles portent l'historique de leurs modifications : qui a changé quoi, et quand. Sans cette trace, une enquête après incident se réduit à des suppositions, et rien ne permet de dire ce qui a été touché ni jusqu'où.
Ce risque ne se vérifie pas depuis l'extérieur, par construction. Il se constate en interne, et surtout dans le régime convenu : un outil qui alerte sans destinataire qui regarde ne couvre rien du tout.
A10:2025 · Mishandling of Exceptional Conditions
Nouvelle catégorie 2025. L'application réagit mal aux erreurs : elle divulgue des informations confidentielles ou bascule dans un mode permissif.
Une erreur serveur qui affiche une stack trace complète à l'utilisateur. Un paiement échoué qui valide quand même la commande. Un appel API externe HS traité par défaut comme un succès.
Les opérations métier composées passent par une transaction. Les contrôles de sécurité échouent par défaut plutôt que de laisser passer. Les pages d'erreur n'exposent rien, et les traitements longs sont conçus pour être rejoués sans dégât.
Des compteurs interrogent la base sur les états que le métier interdit, une facture validée sans ligne de paiement correspondante par exemple. Une tâche planifiée les relève et alerte dès que l'un d'eux cesse d'être à zéro : c'est ce qui rattrape la condition exceptionnelle que personne n'avait vue venir.
Partiellement par le scan, qui provoque des erreurs et lit ce que la réponse laisse filtrer. Le comportement métier en cas d'échec, lui, se vérifie par des tests écrits pour les cas extrêmes, ce qui suppose de les avoir prévus dès la conception.
Sur un projet repris, tout ne se traite pas en même temps
Ces dix risques décrivent une cible, pas un plan de bataille. Sur une application existante qui n'a jamais été regardée sous cet angle, vouloir tout traiter d'un coup revient à dépenser un budget sur des chantiers dont personne n'a mesuré l'urgence.
L'ordre que nous suivons est celui du coût d'une erreur, pas celui du classement. Le contrôle d'accès et l'authentification d'abord : une faille à cet endroit expose des données réelles immédiatement. La configuration et les dépendances ensuite, parce qu'elles se corrigent vite et sans toucher au métier. La conception en dernier, parce qu'elle suppose de rouvrir des décisions, donc du temps et des arbitrages. C'est le cadre que nous posons lors d'une reprise de projet.
Ce que la liste ne dit pas
Ce classement mesure une fréquence d'apparition. Un risque placé en dixième position peut s'avérer destructeur sur votre application, selon vos données et vos accès.
Ce sont des regroupements larges de faiblesses, pas un inventaire. Une application peut n'être concernée par aucune des dix et rester vulnérable sur un point propre à son métier ou à ses intégrations.
Un compte partagé entre plusieurs personnes, un mot de passe transmis par message, un accès jamais révoqué après un départ : l'OWASP ne voit pas l'humain. C'est pourtant la porte d'entrée de la majorité des attaques.
Dernière mise à jour du référentiel
Édition précédente : 2021. Une révision ne décale pas juste des numéros : elle fusionne, scinde, renomme et redéfinit les priorités. C'est pourquoi nous appuyons nos analyses sur un référentiel interne structuré.
Nouveautés de l'édition 2025 : méthodologie et évolutions depuis 2021
A03 Software Supply Chain Failures élargit le sujet des dépendances obsolètes à toute la chaîne : builds, packages et infra. A10 Mishandling of Exceptional Conditions intègre le classement en ciblant le comportement de l'application en cas d'échec.
Le SSRF, qui occupait une entrée à lui seul en 2021, est intégré dans le contrôle d'accès défaillant. Le risque n'a pas disparu, il change d'adresse pour plus de cohérence.
« Identification and Authentication Failures » devient « Authentication Failures », et
« Security Logging and Monitoring Failures » devient « Security Logging and Alerting
Failures ».
Le passage de « Logging and Monitoring » à « Logging and Alerting » n'est pas cosmétique.
On ne demande plus seulement d'enregistrer les événements, mais de
savoir lever une alerte quand le problème est détecté.
La mauvaise configuration grimpe en deuxième position. La cryptographie, l'injection et la conception non sécurisée reculent. Le contrôle d'accès défaillant conserve sa première place.
Ce qui recule est désormais géré par défaut dans nos frameworks : requêtes préparées, hachage des mots de passe, échappement HTML. Ce qui monte relève de l'exploitation : configuration des serveurs et dépendances. C'est un argument très concret pour s'appuyer sur un framework mature plutôt que sur un socle maison : Symfony traite ces trois points par défaut, et les tient à jour à notre place.
Aujourd'hui, la sécurité d'un projet se joue moins dans la ligne de code que dans la façon dont l'application est déployée et maintenue.
FAQ
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Non, et c'est une confusion fréquente. L'OWASP est une fondation qui publie ses référentiels librement : elle ne délivre aucune certification et n'accrédite aucun auditeur. Personne ne peut donc être « certifié OWASP Top 10 ». Ce qui est possible, c'est un rapport d'audit qui dit ce qui a été vérifié, comment, et surtout ce qui ne l'a pas été.
Non. Sur les dix risques du classement, un outil en détecte 3 entièrement, 4 en partie seulement, et laisse 3 hors de sa portée. Ceux-là relèvent de la logique métier : aucun scanner ne devine quel utilisateur a le droit de voir quel document, ni si votre application est correctement surveillée. Un scan vert dit qu'aucune erreur évidente n'a été trouvée depuis l'extérieur, pas que l'application est sûre. C'est un contrôle nécessaire mais jamais suffisant.
Non : une révision ne rend pas une application moins sûre du jour au lendemain, elle réorganise la façon de nommer les risques. Les pratiques qui protégeaient un projet livré sous l'édition 2021 le protègent toujours sous l'édition 2025. Ce qu'il faut reprendre, ce sont les documents qui citent des identifiants, rapports d'audit et cahiers des charges en tête : eux deviennent ambigus, parce qu'un même code ne désigne plus la même famille de risques.
Il n'existe pas de forfait, mais il existe un ordre. Le contrôle d'accès et l'authentification se traitent d'abord, parce qu'une faille à cet endroit expose des données réelles immédiatement. La configuration et les dépendances suivent : elles se corrigent vite et sans toucher au métier. La conception vient en dernier, parce qu'elle suppose de rouvrir des décisions déjà prises. Sur une application en production, c'est un travail qui s'étale sur plusieurs cycles de maintenance, ce n'est pas un chantier unique.
Depuis 2003
Huit éditions en un peu plus de vingt ans, à un rythme de trois à quatre ans. Ce qui suit ne retrace que les inflexions : les révisions qui ont changé la façon de lire le classement, pas chaque permutation de rang.
Présentée en novembre 2025 à l'OWASP Global AppSec DC, publiée en version finale en janvier 2026. Deux catégories inédites, dont la chaîne d'approvisionnement logicielle qui entre directement en troisième position.
Restructuration profonde. Le contrôle d'accès défaillant passe de la cinquième à la première place, la conception non sécurisée entre directement en quatrième, et le XSS est absorbé par l'injection dont il est une forme.
Entrée des entités externes XML (XXE) et de la désérialisation non sécurisée, deux risques venus de la généralisation des API et des formats sérialisés.
Le changement le plus structurant de l'histoire du document : on ne classe plus des vulnérabilités mais des risques, ce qui suppose de tenir compte de la probabilité et de l'impact, et non de la seule existence d'un défaut.
Ce que chaque édition a apporté
Le projet naît dans les premières années de l'OWASP et trouve son public immédiatement : une liste courte, lisible par un non-spécialiste, là où la littérature sécurité de l'époque ne l'était pas.
Ce que chaque édition a apporté
Contactez-nous pour savoir comment nous pouvons vous aider.
