OWASP Top 10 2025 : ce qui change, et les risques qu'un scanner sait détecter

Qu'est-ce que l'OWASP Top 10 2025 ?

L'OWASP Top 10 2025 est un classement de dix catégories de risques pour les applications web, chacune regroupant des faiblesses CWE proches. Pour cette édition, l'OWASP a analysé 589 CWE et en a retenu 248 dans les dix catégories, avec un plafond de 40 par catégorie. Huit catégories viennent de données de tests fournies par des entreprises comme Semgrep, Sonar, Veracode, Contrast Security ou Bugcrowd. Les deux autres sortent d'une enquête auprès de la communauté, parce que l'OWASP juge les données seules incomplètes.

Les équipes sécurité s'en servent comme d'un vocabulaire commun. Formations, grilles de revue de code, rapports de scanners et preuves d'audit sont souvent rangés selon ses catégories, ce qui explique qu'une nouvelle édition se répercute sur les outils, les politiques et les audits.

Quelles sont les dix catégories ?

Les dix catégories de l'OWASP Top 10 2025 sont Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures et Mishandling of Exceptional Conditions. L'OWASP les publie en anglais, et les équipes les citent sous ce nom.

Qu'est-ce qui change par rapport à 2021 ?

Quatre changements comptent pour une équipe de développement : la chaîne d'approvisionnement a sa catégorie, la SSRF passe dans le contrôle d'accès, la gestion des erreurs devient une catégorie, et la mauvaise configuration monte à la deuxième place.

• Software Supply Chain Failures (A03). La catégorie de 2021, Vulnerable and Outdated Components, visait les CVE connues de vos dépendances. Celle de 2025 couvre les défaillances ou compromissions dans le processus de construction, de distribution ou de mise à jour du logiciel, et l'OWASP cite explicitement le serveur de build et la CI/CD parmi ce qu'il faut protéger. Scanner le lockfile ne suffit plus : le pipeline qui construit votre code entre dans le périmètre. Selon les notes de l'OWASP, c'est la catégorie au taux d'incidence moyen le plus élevé des dix.
• La SSRF rejoint Broken Access Control (A01). La falsification de requête côté serveur était la catégorie A10 en 2021. Elle compte désormais parmi les 40 faiblesses du contrôle d'accès défaillant.
• Mishandling of Exceptional Conditions (A10). La nouvelle catégorie vise les programmes qui ne savent pas prévenir, détecter ni traiter les situations inhabituelles et imprévisibles. Parmi ses 24 faiblesses : les messages d'erreur qui divulguent des données sensibles (CWE-209), le déréférencement de pointeur NULL (CWE-476) et le code qui échoue en position ouverte au lieu d'échouer de façon sûre (CWE-636).
• Security Misconfiguration (A02) passe de la cinquième à la deuxième place. La définition de l'OWASP cite désormais les services cloud à côté des systèmes et des applications mal configurés.

Deux catégories changent de nom : Identification and Authentication Failures devient Authentication Failures, et Security Logging and Monitoring Failures devient Security Logging and Alerting Failures. Le déni de service, rebaptisé Lack of Application Resilience, figure dans la section « prochaines étapes » de l'OWASP, hors des dix.

Quel scanner open source détecte quel risque ?

Les scanners statiques open source couvrent largement Injection et Cryptographic Failures, six autres catégories en partie, et peu d'Insecure Design et de Security Logging and Alerting Failures. Le tableau est notre lecture du périmètre documenté de chaque outil, confronté aux pages de catégorie de l'OWASP, au 13 novembre 2026.

Opengrep, le fork de Semgrep sous licence LGPL-2.1, couvre plus de 30 langages et exécute les règles Semgrep sans modification. Son README décrit une analyse de taint à l'intérieur d'un fichier, d'où la mention « flux qui traversent plusieurs fichiers » sur la ligne Injection. Trivy lit les dépendances, l'infrastructure as code, les secrets et les licences, et notre test des outils SCA open source montre ce que lui et OSV-Scanner trouvent sur un vrai lockfile. Gitleaks repère mots de passe, clés d'API et jetons dans les fichiers et l'historique git ; les identifiants écrits en dur (CWE-798) relèvent d'A07 dans la liste 2025, et notre comparatif des scanners de secrets open source le détaille. zizmor est un analyseur statique pour GitHub Actions, avec des audits comme template-injection, unpinned-uses, dangerous-triggers, excessive-permissions et cache-poisoning, qui touchent A03 et A08.

Aucun de ces outils ne voit un paquet malveillant qui n'a pas encore d'avis de sécurité, la brèche par laquelle passe le slopsquatting, l'attaque sur les noms de paquets inventés par les modèles d'IA.

Pourquoi les scanners passent-ils à côté du risque n°1 ?

Les scanners statiques ratent le cœur de Broken Access Control parce que la faille est un contrôle absent, et un contrôle absent n'a pas de motif. Un scanner sait suivre une entrée utilisateur jusqu'à une fonction dangereuse. Il n'a aucune source pour la règle qui dit qu'une facture appartient à un client.

Les jeux de règles le montrent. Le 13 novembre 2026, nous avons compté les règles du jeu communautaire d'Opengrep, une copie des règles de Semgrep de janvier 2025 : 2 007 règles, dont 1 354 portent une catégorie OWASP 2021. L'injection en a 384. Broken Access Control en a 228, mais 114 d'entre elles vérifient les droits d'accès de ressources cloud, surtout en Terraform, et d'autres couvrent le path traversal, le CSRF et les redirections ouvertes. Les trois faiblesses qui décrivent l'autorisation elle-même, CWE-639 (contournement d'autorisation par une clé contrôlée par l'utilisateur), CWE-862 (autorisation manquante) et CWE-863 (autorisation incorrecte), apparaissent dans quatre règles. Trois lisent du code applicatif, chacune pour un seul framework : un find sans périmètre en Ruby on Rails, un contrôleur ASP.NET Core sans attribut d'autorisation, des opérations de données natives en Salesforce Apex. Elles repèrent un contrôle absent ; aucune ne sait dire si un contrôle présent est le bon.

L'OWASP l'écrivait déjà en 2017 : les outils SAST et DAST peuvent détecter l'absence de contrôle d'accès, mais ne peuvent pas vérifier qu'il fonctionne quand il est présent. Voici à quoi cela ressemble dans une route Express :

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

La route exige une connexion, la requête est paramétrée, l'entrée n'atteint jamais de fonction dangereuse. Le scanner n'a rien à signaler. Pourtant, n'importe quel client connecté peut lire n'importe quelle facture en changeant le numéro dans l'URL : une référence directe à un objet non sécurisée, ou IDOR. Le correctif tient en une condition, where: { id: req.params.id, customerId: req.user.customerId }, et seul quelqu'un qui sait que les factures appartiennent aux clients peut l'écrire.

Insecure Design est encore plus hors de portée. La page de l'OWASP le dit sans détour : une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite, puisque les contrôles nécessaires n'ont jamais été créés. Un panier qui accepte une quantité négative passe tous les scanners, comme le montre notre récit du panier à 0 €. Nous couvrons toute la famille dans les failles de logique métier du code généré par IA.

Comment tester le contrôle d'accès ?

On teste le contrôle d'accès avec un test qui tente l'action interdite et attend un refus, un par rôle et par objet qui appartient à quelqu'un. La page 2025 de l'OWASP le demande en toutes lettres : les développeurs et la QA devraient inclure des tests fonctionnels du contrôle d'accès dans leurs tests unitaires et d'intégration.

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Ce test est à la fois la preuve et le garde-fou. Avant le correctif, il échoue : la faille existe dans votre code, pas en théorie. Après le correctif, il passe, et il reste dans la suite pour que la prochaine modification ne rouvre pas le trou. Son coût, c'est de savoir quels objets appartiennent à qui, précisément ce qu'un scanner ignore.

Trois habitudes font l'essentiel du chemin :

1. Tout refuser par défaut. Chaque nouvelle route naît fermée, et l'accès passe par un contrôle explicite qui nomme le propriétaire ou le rôle.
2. Limiter chaque requête à l'utilisateur. Chercher les enregistrements à travers l'utilisateur ou le tenant courant, jamais avec un identifiant brut tiré de la requête.
3. Un test de refus par objet sensible. Factures, documents, comptes, tout ce qui a un propriétaire reçoit un test où le mauvais utilisateur est refusé.

Que change l'OWASP Top 10 quand des agents IA écrivent le code ?

Les catégories ne changent pas quand des agents de code comme Claude Code, Cursor, GitHub Copilot ou OpenAI Codex écrivent le code, mais le volume et la vitesse, si. Une équipe qui livre plus de modifications par semaine a besoin des scanners à chaque modification, et d'une relecture des contrôles d'accès sur chaque nouvel endpoint, parce qu'un agent écrit une route qui fonctionne aussi facilement qu'il saute un contrôle de propriétaire qu'on ne lui a jamais décrit.

Les mêmes agents peuvent aussi faire le travail défensif. Un agent qui lit le code peut cartographier chaque endpoint, chercher quels rôles y accèdent, écrire le test de refus, le lancer et montrer s'il échoue. C'est la part de l'OWASP Top 10 que les scanners laissent de côté, et un agent de code peut l'abattre au rythme où il écrit du code. Notre guide de la sécurité des agents de code IA traite l'autre versant : ce que l'agent lui-même a le droit d'exécuter.

Où se place CybeDefend ?

CybeDefend Open Source arrive bientôt, et couvre les deux moitiés de cet article. Une commande dans votre agent de code, /cybedefend, lance un audit complet en deux couches. D'abord les scanners AppSec, open source, dont Opengrep, Trivy, Gitleaks et zizmor, pour le code, les dépendances, les secrets, l'infrastructure as code, la CI/CD et les conteneurs : les risques à motif du tableau ci-dessus. Gardez ceux que vous voulez et ajoutez les vôtres.

Ensuite le scanner IA, lancé par votre agent de code. Les scanners cherchent des motifs. Le scanner IA lit ce que votre code est censé faire et trouve où il casse, dans la logique métier, les droits d'accès et les failles qui n'apparaissent qu'à l'exécution : les lignes A01, A06 et A07. Il prouve chaque faille avec un exploit écrit sous forme de test dans votre propre suite, comme celui ci-dessus. Pas de modèle en plus ni de clé d'API : l'IA, c'est l'agent de code que vous utilisez déjà.

Sous les deux couches, il y a toute notre plateforme, un ASPM agentique. Elle garde chaque finding dans une seule file, et ses rapports de sécurité rattachent les findings à l'OWASP Top 10 et au CWE Top 25. Pour lancer l'audit sur votre propre code dès l'ouverture, inscrivez-vous sur la liste d'attente de CybeDefend Open Source.

Questions fréquentes

Quelles sont les nouveautés de l'OWASP Top 10 2025 ?

Deux catégories font leur entrée : Software Supply Chain Failures en A03, qui étend l'ancienne Vulnerable and Outdated Components aux systèmes de build et à la CI/CD, et Mishandling of Exceptional Conditions en A10. La SSRF passe dans Broken Access Control, et Security Misconfiguration monte de la cinquième à la deuxième place.

Quel est le risque n°1 de l'OWASP Top 10 2025 ?

Broken Access Control, le contrôle d'accès défaillant, comme en 2021. La catégorie regroupe 40 faiblesses, du path traversal et du CSRF jusqu'à l'autorisation manquante et aux IDOR, et depuis 2025 elle inclut aussi la SSRF.

La SSRF fait-elle encore partie de l'OWASP Top 10 ?

Oui, dans A01 Broken Access Control. La SSRF avait sa propre catégorie, A10, en 2021 ; l'édition 2025 l'a intégrée au contrôle d'accès.

Un outil SAST suffit-il à couvrir l'OWASP Top 10 ?

Non. Un outil SAST couvre bien Injection et Cryptographic Failures, et une partie de plusieurs autres catégories. Les risques liés aux dépendances et au pipeline demandent un outil SCA et un scanner CI/CD, et le contrôle d'accès comme la conception demandent des tests et une relecture par quelqu'un qui connaît les règles de l'application.

À quel rythme l'OWASP Top 10 est-il mis à jour ?

Sans calendrier fixe. L'édition 2025 est la huitième, quatre ans après la liste de 2021.

CybeDefend est-il open source ?

Son édition open source, CybeDefend Open Source, arrive bientôt : toute notre plateforme, un ASPM agentique, libre de tourner sur vos propres serveurs. La commande /cybedefend enchaîne les scanners AppSec open source et un scanner IA lancé par votre agent de code, et garde chaque finding dans une seule file. Inscrivez-vous sur la liste d'attente de CybeDefend Open Source.