Vulnérabilités : CVE, CVSS et le Top 10 de l'OWASP
Comment on nomme, note et priorise une vulnérabilité, et les grandes familles de failles des applications web selon le Top 10 2025 de l'OWASP.
Elouan
Série Comprendre les attaques · article 4 sur 4
- La kill chain et MITRE ATT&CK
- Le phishing et l'authentification des mails
- Les rançongiciels, de l'intrusion à la rançon
- Vulnérabilités : CVE, CVSS et le Top 10 de l'OWASP
Chaque semaine, des dizaines de nouvelles vulnérabilités sont publiées. Aucune organisation ne peut tout corriger immédiatement. Il faut donc savoir identifier, évaluer et prioriser. Et pour les applications web, qui sont souvent la première surface exposée, il faut connaître les grandes familles de failles que recense l’OWASP.
Nommer une vulnérabilité : CVE et CWE
| Identifiant | Ce que c’est | Exemple |
|---|---|---|
| CVE | Une vulnérabilité précise, dans un produit et des versions précis | CVE-2021-44228 (Log4Shell, dans Apache Log4j) |
| CWE | Une catégorie générique de faiblesse | CWE-89 (injection SQL), CWE-79 (XSS) |
Le programme CVE est géré par MITRE avec de nombreux partenaires. En France, les avis et alertes du CERT-FR reprennent les CVE importantes et précisent les produits concernés et les correctifs.
Mesurer la sévérité : CVSS
Le CVSS (Common Vulnerability Scoring System), maintenu par le FIRST, donne une note de 0 à 10 à partir de critères techniques : la vulnérabilité est-elle exploitable à distance ? Faut-il être authentifié ? Une action de l’utilisateur est-elle nécessaire ? Quel impact sur la confidentialité, l’intégrité, la disponibilité ?
| Score | Sévérité |
|---|---|
| 9,0 – 10,0 | Critique |
| 7,0 – 8,9 | Élevée |
| 4,0 – 6,9 | Moyenne |
| 0,1 – 3,9 | Faible |
La version actuelle est CVSS 4.0 (2023), mais on rencontre encore beaucoup de scores en 3.1.
La sévérité n’est pas la priorité
Le score CVSS de base mesure la gravité technique, pas le risque réel pour l’organisation. Une faille critique sur un composant interne inaccessible peut être moins urgente qu’une faille « élevée » activement exploitée sur un VPN exposé à Internet.
Prioriser : exploitation réelle et exposition
Pour décider quoi corriger en premier, on croise plusieurs sources :
| Critère | Source |
|---|---|
| Exploitation confirmée | Catalogue KEV de la CISA, alertes du CERT-FR, veille |
| Probabilité d’exploitation | Score EPSS du FIRST (probabilité sur les 30 prochains jours) |
| Exposition | L’actif est-il joignable depuis Internet ? Depuis tout le réseau interne ? |
| Criticité de l’actif | Contrôleur de domaine, VPN, serveur de données sensibles… |
| Sévérité | Score CVSS |
Une règle de priorité simple
En premier : ce qui est exploité activement et exposé à Internet (VPN, pare-feu, passerelles de messagerie, serveurs web). Ensuite : les actifs critiques internes (Active Directory, sauvegardes). Puis le reste selon le score et l’EPSS. Les équipements de bordure sont depuis plusieurs années parmi les cibles favorites des attaquants.
Un zero-day est une vulnérabilité exploitée avant qu’un correctif existe. Dans ce cas, on applique les mesures de contournement publiées par l’éditeur ou le CERT-FR, on réduit l’exposition, et on cherche des traces de compromission antérieures.
Le Top 10 de l’OWASP (2025)
L’OWASP (Open Worldwide Application Security Project) publie régulièrement la liste des risques les plus importants pour les applications web. La version 2025 :
| Rang | Catégorie | En une phrase |
|---|---|---|
| A01 | Contrôle d’accès défaillant | Un utilisateur peut voir ou faire ce qu’il ne devrait pas |
| A02 | Mauvaise configuration de sécurité | Paramètres par défaut, fonctions inutiles activées, messages d’erreur trop bavards |
| A03 | Défaillances de la chaîne d’approvisionnement logicielle | Dépendances vulnérables ou compromises, chaîne de construction non maîtrisée |
| A04 | Défaillances cryptographiques | Données sensibles mal protégées, algorithmes faibles |
| A05 | Injection | Des données de l’utilisateur interprétées comme du code (SQL, commandes, XSS…) |
| A06 | Conception non sécurisée | Une faille dans la logique même de l’application |
| A07 | Défaillances d’authentification | Mots de passe faibles acceptés, sessions mal gérées, absence de MFA |
| A08 | Défaillances d’intégrité des logiciels et des données | Mises à jour ou données acceptées sans vérification |
| A09 | Défaillances de journalisation et d’alerte | On ne voit pas les attaques, ou trop tard |
| A10 | Mauvaise gestion des conditions exceptionnelles | Erreurs mal traitées qui ouvrent une faille ou divulguent des informations |
Le contrôle d’accès (A01)
C’est la première catégorie, et de loin la plus fréquente dans les tests. Exemples typiques :
- IDOR : changer
facture?id=1042enfacture?id=1043et voir la facture d’un autre client ; - accéder à une page d’administration simplement en connaissant son adresse ;
- une vérification de droits faite seulement dans le navigateur (bouton masqué), mais pas sur le serveur.
La règle : vérifier les droits côté serveur, à chaque requête, en refusant par défaut.
L’injection (A05)
L’injection survient quand une application mélange des données fournies par l’utilisateur avec du code (une requête SQL, une commande système, du HTML) sans les séparer correctement. L’interpréteur peut alors exécuter une partie des données comme si c’était du code. Le cross-site scripting (XSS) en est une forme : du contenu injecté s’exécute dans le navigateur d’autres utilisateurs.
Les défenses :
- requêtes paramétrées pour les bases de données : le code SQL et les données voyagent séparément ;
- validation des entrées côté serveur (format, longueur, liste de valeurs autorisées) ;
- encodage des sorties selon le contexte (HTML, JavaScript, URL) contre le XSS, et une politique CSP ;
- éviter d’appeler des commandes système avec des données de l’utilisateur.
Et le WAF ?
Un WAF (pare-feu applicatif web) filtre une partie des attaques connues et fait gagner du temps en attendant un correctif. Mais il se contourne : il complète un code sûr, il ne le remplace pas.
La chaîne d’approvisionnement (A03)
Nouvelle venue en 2025 sous cette forme, elle couvre les risques liés à tout ce dont l’application dépend : bibliothèques vulnérables ou compromises, paquets malveillants publiés sous un nom proche d’un paquet connu, outils de compilation et de publication compromis. Les défenses : inventaire des dépendances (SBOM), mises à jour, vérification des signatures, et un œil sur la provenance des paquets.
C’est la fin de la série sur les attaques : la suivante passe du côté de ceux qui les détectent.
L'essentiel
- Une CVE est l'identifiant unique d'une vulnérabilité publique (CVE-année-numéro). Une CWE est une catégorie de faiblesse (par exemple CWE-89 pour l'injection SQL).
- Le score CVSS (de 0 à 10) mesure la sévérité technique : critique de 9,0 à 10, élevée de 7,0 à 8,9, moyenne de 4,0 à 6,9, faible de 0,1 à 3,9. La version actuelle est CVSS 4.0.
- La sévérité ne suffit pas pour prioriser : on regarde aussi l'exploitation réelle (catalogue KEV de la CISA, avis du CERT-FR), la probabilité d'exploitation (EPSS) et l'exposition de l'actif.
- Une vulnérabilité « zero-day » est exploitée avant qu'un correctif soit disponible ou connu.
- Top 10 OWASP 2025 : A01 contrôle d'accès défaillant, A02 mauvaise configuration, A03 chaîne d'approvisionnement logicielle, A04 défaillances cryptographiques, A05 injection, A06 conception non sécurisée, A07 défaillances d'authentification, A08 intégrité des logiciels et des données, A09 journalisation et alertes défaillantes, A10 mauvaise gestion des conditions exceptionnelles.
- La défense contre l'injection : requêtes paramétrées et validation des entrées côté serveur, jamais de concaténation de données utilisateur dans une requête ou une commande.
Idées reçues
Une vulnérabilité CVSS 9,8 et une autre à 7,5 : laquelle corriger en premier ?
L'erreur courante. Répondre systématiquement la 9,8.
En réalité. Pas forcément. Si la 7,5 est activement exploitée (présente dans le catalogue KEV ou signalée par le CERT-FR) et touche un équipement exposé à Internet, alors que la 9,8 concerne un composant interne non joignable, la 7,5 est plus urgente. On combine sévérité, exploitation réelle, probabilité (EPSS) et exposition.
Quelle différence entre une CVE et une CWE ?
L'erreur courante. Les confondre.
En réalité. Une CVE identifie une vulnérabilité précise dans un produit précis (par exemple une faille d'une version donnée d'un VPN). Une CWE est une catégorie générique de faiblesse (par exemple CWE-79 pour le XSS). Une CVE est généralement rattachée à une ou plusieurs CWE.
Le chiffrement HTTPS protège-t-il une application contre l'injection SQL ?
L'erreur courante. Répondre oui.
En réalité. Non. TLS protège les données en transit entre le navigateur et le serveur. L'injection exploite la façon dont l'application traite les données reçues : le contenu malveillant arrive chiffré, puis est déchiffré et traité par le serveur. La défense est dans le code (requêtes paramétrées) et, en complément, un WAF.
Pourquoi le contrôle d'accès défaillant est-il en tête du Top 10 ?
L'erreur courante. Penser qu'il s'agit seulement de mots de passe.
En réalité. Il regroupe tous les cas où un utilisateur peut faire ou voir ce qu'il ne devrait pas : accéder aux données d'un autre client en changeant un identifiant dans l'URL (IDOR), atteindre une fonction d'administration sans être administrateur, contourner une vérification faite seulement côté navigateur. C'est très fréquent et souvent lourd de conséquences. La règle : vérifier les droits côté serveur, à chaque requête.
Tester ses connaissances
Références
- The Web Application Hacker's Handbook (2e éd.)Dafydd Stuttard, Marcus Pinto · Wiley
- Real-World Bug HuntingPeter Yaworski · No Starch Press