OWASP Top 10 2025 : les 10 risques de sécurité web
à connaître

Si la cybersécurité web avait un best-of, ce serait l'OWASP Top 10. C'est la liste de référence : les dix catégories de failles les plus critiques des applications web, compilées par la communauté OWASP à partir de montagnes de données réelles. Développeurs, pentesters, RSSI, auditeurs ISO 27001 : tout le monde y revient. C'est un peu le "permis de conduire" de l'AppSec.

Bonne nouvelle : une nouvelle édition est sortie. Publiée par l'OWASP en 2025, l'OWASP Top 10 2025 remplace la version 2021 qui régnait depuis quatre ans. Et ça bouge : deux nouvelles catégories, des renommages, et le SSRF qui se fait carrément absorber. Si vous étiez resté sur le classement 2021, c'est le moment de mettre à jour vos slides.

Ce qui change entre 2021 et 2025

La méthodologie 2025 s'appuie sur du lourd : environ 220 000 CVE analysées, 589 CWE cartographiées, plus de 2,8 millions d'applications testées, le tout croisé avec une enquête auprès des praticiens. Résultat, trois mouvements à retenir :

• Deux nouvelles catégories : Software Supply Chain Failures (A03, l'ancienne catégorie "composants vulnérables" élargie à toute la chaîne d'approvisionnement) et Mishandling of Exceptional Conditions (A10, totalement inédite).
• SSRF a disparu de la liste en tant que catégorie autonome : il a été fusionné dans le Broken Access Control (A01). Le numéro 1 ne fait que grossir.
• Security Misconfiguration grimpe de la 5e à la 2e place. À l'ère du tout-cloud et du tout-config-as-code, mal régler ses services coûte cher.

Maintenant, attaquons la liste 2025 dans l'ordre. Pour chaque risque : c'est quoi, un exemple concret, et comment s'en prémunir.

A01:2025, Broken Access Control

Le boss final, encore et toujours numéro 1. Le contrôle d'accès, c'est la règle qui empêche un utilisateur d'agir au-delà de ses droits. Quand il est cassé, n'importe qui peut lire, modifier ou supprimer des données qui ne lui appartiennent pas, ou déclencher des actions réservées aux admins. Depuis 2025, le SSRF (forcer le serveur à émettre des requêtes vers des cibles internes) entre aussi dans cette famille. Le CSRF, qui fait exécuter une action à un utilisateur légitime à son insu, y est rangé depuis l'édition 2021 : c'est le jeton CSRF qui l'empêche, quand il est vérifié.

Exemple concret : l'IDOR (Insecure Direct Object Reference). Vous consultez votre facture à l'URL /api/invoices/1042. Vous changez 1042 en 1043... et vous tombez sur la facture du client d'à côté. Pas d'exploit sophistiqué, juste un compteur incrémenté.

La parade : "deny by default" (tout est interdit sauf autorisation explicite), vérification des droits côté serveur pour chaque ressource (jamais en se fiant à l'UI), et identifiants d'objets non devinables. Pour le SSRF : valider/allowlister les URL sortantes et segmenter le réseau.

A02:2025, Security Misconfiguration

La nouvelle vedette. Promue de la 5e à la 2e place, la mauvaise configuration regroupe tout ce qui est mal réglé : services avec leurs paramètres par défaut, comptes admin/admin jamais changés, buckets cloud en accès public, en-têtes de sécurité absents, messages d'erreur trop bavards, ports de debug ouverts en prod.

Exemple concret : un bucket S3 laissé en lecture publique "le temps d'un test", qui finit indexé par un moteur de recherche avec, dedans, les exports clients en CSV. Classique, et toujours autant de dégâts.

La parade : durcissement (hardening) systématique, suppression des fonctionnalités et comptes inutiles, configuration en infrastructure-as-code versionnée et auditée, et une revue de config qui suit l'appli de la recette à la prod.

A03:2025, Software Supply Chain Failures

La grande nouveauté. Anciennement "composants vulnérables et obsolètes", cette catégorie a été élargie à toute la chaîne d'approvisionnement logicielle : dépendances open source, registres de paquets, plugins CI/CD, images de conteneurs, scripts tiers. Votre code peut être parfait ; si une de vos 1 200 dépendances est compromise, c'est vous qui tombez.

Exemple concret : un mainteneur de paquet npm se fait pirater, pousse une version vérolée, et des milliers de builds l'installent automatiquement (cf. les attaques de type typosquatting et compromission de mainteneurs qui défraient régulièrement la chronique). Côté applicatif, un plugin tiers vulnérable suffit : on montre comment un plugin WordPress mène à une exécution de code à distance sur WordPress.

La parade : inventaire des dépendances (SBOM), analyse de composition logicielle (SCA), épinglage des versions et vérification des signatures, et un pipeline CI/CD verrouillé (le maillon faible, c'est souvent là).

A04:2025, Cryptographic Failures

Quand la crypto échoue à protéger les données. On parle de données sensibles transmises en clair, d'algorithmes obsolètes (MD5, SHA-1, DES), de clés codées en dur, de mots de passe stockés sans salage, ou d'une "crypto maison" bricolée. Le problème n'est pas la crypto en soi, c'est la mauvaise crypto.

Exemple concret : une base de mots de passe stockés en MD5 non salé. Une fuite, un coup de rainbow table, et 80 % des comptes sont craqués en quelques minutes.

La parade : TLS partout, algorithmes modernes (AES, ChaCha20, et bcrypt/argon2 pour les mots de passe), gestion des clés via un coffre-fort (KMS/Vault), et surtout : ne jamais rouler sa propre crypto.

A05:2025, Injection

La doyenne du classement. Rétrogradée à la 5e place mais toujours redoutable, l'injection survient quand des données non fiables sont interprétées comme du code/une commande : SQL, NoSQL, commandes OS, LDAP... et le XSS (injection de scripts côté client) entre dans cette famille.

Exemple concret : une requête SQL construite par concaténation. L'attaquant saisit ' OR '1'='1 dans un champ login :

-- Code vulnérable : la saisie est concaténée dans la requête
query = "SELECT * FROM users WHERE name = '" + input + "'"

-- Saisie de l'attaquant :  ' OR '1'='1

-- Requête réellement exécutée, la condition est toujours vraie
-- et la clause de filtrage ne filtre plus rien :
SELECT * FROM users WHERE name = '' OR '1'='1'

La parade : requêtes paramétrées (prepared statements) ou ORM, validation et échappement des entrées, principe du moindre privilège sur le compte de base de données. La règle d'or : ne jamais mélanger code et données. Le cas de l'injection SQL détaille les familles d'attaques et pourquoi les requêtes préparées sont la seule défense qui tient.

A06:2025, Insecure Design

Le bug qui n'est pas un bug. Ici, la faille n'est pas dans l'implémentation mais dans la conception : une logique métier qui ne prévoit pas l'abus, l'absence de modélisation des menaces, un workflow qui fait confiance à l'utilisateur là où il ne faut pas. Vous pouvez coder parfaitement une mauvaise idée.

Exemple concret : un "mot de passe oublié" basé sur des questions secrètes ("nom de votre animal ?") dont les réponses traînent sur les réseaux sociaux. Le code est nickel, le design est cassé.

La parade : threat modeling dès la conception, patterns sécurisés réutilisables, tests de la logique métier, et un cycle de développement sécurisé (SSDLC) qui intègre la sécurité en amont, pas en rustine finale.

A07:2025, Authentication Failures

Renommée (exit "Identification and..."). Tout ce qui touche à la vérification de l'identité : mots de passe faibles autorisés, absence de MFA, attaques par force brute non limitées, gestion de session bancale (tokens prévisibles, sessions qui n'expirent jamais), credential stuffing.

Exemple concret : un formulaire de connexion sans rate limiting ni MFA. L'attaquant rejoue 50 000 couples email/mot de passe issus d'une fuite précédente ; un certain pourcentage passe, parce que les gens réutilisent leurs mots de passe.

La parade : MFA généralisée, politiques de mots de passe alignées sur les recommandations modernes (longueur > complexité arbitraire), limitation des tentatives, sessions robustes avec expiration et rotation. Idéalement, déléguer l'auth à un service centralisé et durci plutôt que de la réinventer.

A08:2025, Software or Data Integrity Failures

Quand on fait confiance sans vérifier l'intégrité. Mises à jour non signées, désérialisation de données non fiables, pipelines CI/CD qui déploient sans contrôle d'intégrité. Cousine de la supply chain, cette catégorie cible le moment où du code ou des données sont acceptés sans preuve qu'ils n'ont pas été altérés.

Exemple concret : une appli qui télécharge ses mises à jour automatiques depuis un serveur en HTTP sans vérifier de signature. Un attaquant en position d'intercepteur livre sa propre "mise à jour"... et exécute son code sur tous les clients.

La parade : signatures numériques sur les artefacts et mises à jour, vérification des intégrités, désérialisation prudente (éviter les formats dangereux, valider le contenu), et durcissement du pipeline de build.

A09:2025, Security Logging and Alerting Failures

Renommée "Alerting" plutôt que "Monitoring". La nuance compte : il ne suffit pas de journaliser, il faut alerter et réagir. Sans journalisation suffisante ni détection, une intrusion peut durer des mois. Le délai moyen de détection d'une compromission se compte encore en semaines.

Exemple concret : 10 000 tentatives de connexion échouées en une nuit, et... aucune alerte. Personne ne regarde, rien ne remonte. L'attaquant a tout le temps du monde.

La parade : journaliser les évènements de sécurité (auth, accès, erreurs), centraliser (SIEM), définir des alertes actionnables, et tester son plan de réponse à incident. Des logs que personne ne lit ne servent à rien.

A10:2025, Mishandling of Exceptional Conditions

La grande inédite de 2025. Cette catégorie cible la mauvaise gestion des cas exceptionnels et des erreurs : exceptions non gérées, états d'échec laissés dans un mode dégradé non sécurisé ("fail open" au lieu de "fail closed"), logique d'erreur qui révèle trop d'informations ou contourne les contrôles. Bref, ce qui se passe quand ça ne se passe pas comme prévu.

Exemple concret : un middleware d'autorisation qui, en cas d'exception (base injoignable, token mal formé), laisse passer la requête "par sécurité pour ne pas casser le service". Résultat : il suffit de provoquer l'erreur pour court-circuiter le contrôle d'accès.

La parade : "fail closed" par défaut (en cas de doute, on refuse), gestion explicite et homogène des exceptions, messages d'erreur génériques côté utilisateur (détails dans les logs uniquement), et tests des chemins d'échec, pas seulement du "happy path".

Le tableau récap des 10 risques 2025

Comment on teste tout ça (et pourquoi un scan ne suffit pas)

Connaître la liste, c'est bien. Savoir si votre application y est vulnérable, c'est autre chose. Un scanner automatisé attrapera une partie des injections et des composants obsolètes, mais sera aveugle sur le Broken Access Control, l'Insecure Design ou la mauvaise gestion des exceptions : ça demande de comprendre la logique métier et de raisonner comme un attaquant. C'est précisément le métier du pentest. Et le Top 10 n'est pas une méthode de test, juste une liste de risques : pour savoir quoi vérifier et comment, l'OWASP publie deux autres référentiels, ASVS et WSTG, que tout pentest sérieux suit d'assez près.

Chez own2pwn, les missions de pentest web blackbox et pentest web whitebox sont cadrées pour couvrir l'intégralité de l'OWASP Top 10, avec exploitation manuelle des failles pour distinguer le vrai du faux positif. Pour comprendre où s'arrête un scanner et où commence le travail humain, notre article pentest vs scan de vulnérabilité fait le tri.

Côté outillage automatisé, le combo SAST / DAST / IAST boosté à l'IA permet de détecter en continu une bonne part de ces risques dès le développement, surtout une fois branché au pipeline, comme on le montre dans intégrer SAST et DAST dans la CI/CD. C'est l'approche de SecAI, notre plateforme AppSec AI-native : l'automatisation balaie le gros du volume, le pentester se concentre sur ce que la machine ne sait pas voir.

À retenir

• La version de référence est désormais l'OWASP Top 10 2025, qui remplace celle de 2021.
• Broken Access Control reste numéro 1 et absorbe le SSRF ; Security Misconfiguration bondit à la 2e place.
• Deux nouvelles catégories : Software Supply Chain Failures (A03) et Mishandling of Exceptional Conditions (A10).
• C'est une liste de sensibilisation : la traiter ne garantit pas la sécurité, c'est le socle minimal.
• Les catégories "logique" (Access Control, Insecure Design, Exceptions) échappent largement aux scanners : le pentest manuel reste indispensable.

Pour la source officielle et le détail de chaque catégorie, direction le site de l'OWASP Top 10 2025 et son introduction méthodologique. Et si vous voulez savoir lesquels de ces dix risques concernent réellement votre application, parlons-en.

Questions fréquentes