OWASP Top 10 2025 : les 10 risques de sécurité web
à connaître
Le classement OWASP a changé en 2025. Broken Access Control toujours en tête, deux nouvelles catégories, SSRF avalé, et le SSDLC qui prend du galon. On vous explique les 10 risques de sécurité web, avec un exemple concret et la parade pour chacun. Sans jargon.
Maxime Jérôme··12 min de lecture
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. Annoncée en novembre 2025 à l'OWASP Global AppSec de Washington et finalisée début 2026, 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.
Une liste de risques, pas un checklist magique
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.
OWASP TOP 10 2021 OWASP TOP 10 2025
─────────────────── ───────────────────
A01 Broken Access Control → A01 Broken Access Control (+ SSRF)
A02 Cryptographic Failures → A02 Security Misconfiguration ↑↑↑
A03 Injection → A03 Software Supply Chain NEW★
A04 Insecure Design → A04 Cryptographic Failures
A05 Security Misconfig. → A05 Injection
A06 Vulnerable Components → A06 Insecure Design
A07 Auth Failures → A07 Authentication Failures
A08 Soft/Data Integrity → A08 Software/Data Integrity
A09 Logging & Monitoring → A09 Logging & Alerting Failures
A10 SSRF → A10 Mishandling Exceptions NEW★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.
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).
Vous ne lisez pas le code de vos dépendances
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 (concaténation)
query = "SELECT * FROM users WHERE name = '" + input + "'"
// Saisie de l'attaquant : ' OR '1'='1
// Requête réellement exécutée :
SELECT * FROM users WHERE name = '' OR '1'='1'
// └── toujours vrai → toutes les lignesLa 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.
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 & Alerting Failures
Renommée « Alerting » plutôt que « Monitoring ». Le nuance compte : il ne suffit pas de logger, 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
| Code | Catégorie | En une phrase |
|---|---|---|
| A01 | Broken Access Control | Agir au-delà de ses droits (IDOR, SSRF). |
| A02 | Security Misconfiguration | Réglages par défaut, services mal durcis. |
| A03 | Software Supply Chain Failures | Dépendances et pipeline compromis. |
| A04 | Cryptographic Failures | Données mal chiffrées ou en clair. |
| A05 | Injection | Données interprétées comme du code (SQL, XSS). |
| A06 | Insecure Design | Faille de conception, pas de code. |
| A07 | Authentication Failures | Identité mal vérifiée, sessions faibles. |
| A08 | Software or Data Integrity Failures | Confiance sans vérification d'intégrité. |
| A09 | Logging & Alerting Failures | On ne voit pas, on n'alerte pas. |
| A10 | Mishandling of Exceptional Conditions | Les cas d'erreur ouvrent des brèches. |
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.
Chez own2pwn, nos missions de pentest web blackbox et pentest web whitebox couvrent 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. 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 (finalisée début 2026), 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.
Articles liés
appsec
EASM et conformité NIS2 : cartographier sa surface d'attaque externe
On ne protège pas ce qu'on ne voit pas. Entre l'EASM (External Attack Surface Management) et l'article 21 NIS2, voici comment cartographier votre surface d'attaque externe, traquer le shadow IT et corréler les CVE avant l'attaquant.
appsec
Pentest, scan de vulnérabilité ou EASM : quelles différences ?
« On a fait un scan, on est bon. » Spoiler : non. Test d'intrusion, scanner de vulnérabilités et EASM répondent à trois questions différentes. On démêle tout : automatisé vs humain, faux positifs, exploitabilité, et lequel choisir.
appsec
SAST, DAST, IAST : comparatif et ce que l'IA change en 2026
SAST, DAST, IAST : trois familles d'outils, trois manières de chasser les failles applicatives. Définitions, forces, limites, faux positifs, et ce que le SAST IA et le DAST IA changent vraiment en 2026 (sans le bullshit marketing).