CWE-20 : validation des entrées insuffisante, la classe que le MITRE déconseille

Dix-huitième du CWE Top 25 2025, et c’est l’entrée la plus instructive du classement, non pour ce qu’elle décrit, mais pour ce que sa présence révèle. Le libellé officiel est Improper Input Validation, « validation incorrecte des entrées ». Le catalogue lui attribue par ailleurs une note de mappage sans ambiguïté : usage déconseillé.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Le produit reçoit une entrée ou des données, mais ne valide pas (ou valide incorrectement), que cette entrée possède les propriétés requises pour être traitée de façon sûre et correcte.

La définition est si large qu’elle englobe la majeure partie du catalogue, et le MITRE a pris soin d’y ajouter une précision de vocabulaire qui change la lecture : dans CWE, « validation » désigne l’acte de vérifier qu’une entrée est déjà sûre telle quelle. Ce n’est pas la même chose que de garantir un traitement sûr. Échapper une chaîne avant de l’écrire dans une page, paramétrer une requête, encoder une sortie : ce sont des transformations, non des validations, et elles relèvent d’autres entrées. L’amalgame est si répandu que le catalogue le signale explicitement comme le principal usage abusif de cette classe.

Autrement dit : CWE-20 décrit le cas où l’application aurait dû refuser une entrée et ne l’a pas fait. Elle ne décrit pas le cas où l’application a accepté une entrée légitime et l’a mal traitée ensuite : qui est le cas de l’immense majorité des injections.

Sa place dans l’arbre, et pourquoi son usage est déconseillé

CWE-20 est une classe de premier niveau, fille du pilier CWE-707 (« neutralisation incorrecte »). Sous elle, le catalogue aligne des dizaines d’entrées, dont une série de variantes qui datent d’une autre époque du web : plusieurs concernent les formulaires de validation d’un cadre applicatif Java des années 2000, témoignage archéologique amusant de ce qu’était la sécurité applicative quand ces numéros ont été attribués.

Le point important est la note de mappage, que le MITRE motive en quatre arguments :

la classe est couramment mal employée dans les rapports pauvres en information, quand une entrée plus précise existait ;
elle ne sert pas à l’analyse de tendance, un classement où elle figure mesure donc en partie la qualité des déclarations ;
elle est une classe de premier niveau, donc trop haute pour désigner une cause racine ;
elle est souvent choisie alors que le problème réel est une transformation incorrecte, et non une validation manquante.

Trois autres entrées du Top 25 portent la même mention : CWE-284, le contrôle d’accès défaillant au rang 19, CWE-200, l’exposition d’information sensible au rang 20, et, au cran inférieur de sévérité, CWE-77, l’injection de commande au rang 23, marquée « admise sous réserve de relecture ». Quatre entrées sur vingt-cinq que le catalogue lui-même recommande d’éviter : c’est l’information la plus utile que donne le classement sur la façon dont les vulnérabilités sont déclarées.

Pourquoi elle est si haut

Parce que c’est la case qu’on coche quand on manque de temps. Une autorité de numérotation qui publie une vulnérabilité doit lui attribuer un type ; en l’absence d’analyse de cause racine, la validation des entrées est la réponse qui n’est jamais fausse. Le résultat est mécanique : des milliers de vulnérabilités s’accumulent sous une classe trop vague pour servir à quoi que ce soit.

Le MITRE en a tiré les conséquences pour l’édition 2025 : un quart des vulnérabilités de la fenêtre d’observation a été réanalysé, précisément pour corriger les attributions trop abstraites, et 281 autorités de numérotation ont été sollicitées. Que CWE-20 figure encore au rang 18 après ce travail en dit long sur le volume initial.

Il existe toutefois des cas où cette classe est la bonne réponse, et ils méritent d’être cités pour ne pas jeter l’entrée avec l’eau du bain : une longueur reçue qui n’est pas comparée à la taille disponible, un type numérique accepté hors de sa plage, un identifiant dont le format n’est pas contrôlé avant usage. Dans ces situations, l’entrée devait être refusée, point.

Le mécanisme, et où le site le traite

Le mécanisme est trop général pour avoir une page ; ce qui en a une, ce sont les pratiques qui le traitent. Sécuriser un contrat API-first dès la conception est la réponse structurelle : un schéma qui décrit les types, les plages et les formats admis transforme la validation en propriété du contrat plutôt qu’en vigilance du développeur. Intégrer SAST, DAST et IAST dans une CI/CD couvre la détection, et revoir le code de sécurité au-delà du linter la relecture.

Pour la lecture des rapports (qui est le vrai sujet de cette page), comment lire un rapport OWASP Top 10 explique quoi faire d’une ligne qui annonce une catégorie sans désigner un défaut.

Ce qu’une équipe en fait

Refuser l’attribution vague. Quand un rapport cite CWE-20, la question à poser est : quelle entrée plus précise s’applique ? Un scanner qui classe une injection SQL en validation d’entrées n’a pas identifié la cause, et le ticket qui en découle ne dira pas quoi corriger.

Valider par schéma, à la frontière. Types, plages, longueurs, formats, énumérations : déclarés une fois, appliqués automatiquement à chaque requête. C’est la seule forme de validation qui résiste à l’ajout de nouveaux points d’entrée.

Ne pas confondre valider et transformer. Une entrée validée reste dangereuse dans un autre contexte : le nom d’utilisateur conforme au format attendu doit toujours être échappé avant d’être écrit dans une page. Les deux gestes sont nécessaires, à deux endroits différents du code, et croire que le premier dispense du second est l’origine d’une bonne partie des injections.

Sources

CWE-20: Improper Input Validation, MITRE, liste 4.20 : définition, note de mappage « Discouraged » et sa justification.
2025 CWE Top 25, MITRE : rang 18.

🐝 Ce qui arrive si on s’en passe

Une équipe qui accepte les attributions vagues travaille sur des tickets qui ne désignent rien. « Validation d’entrées insuffisante sur le module de facturation » ne dit ni quelle entrée, ni quelle propriété manquante, ni ce que le code en fait ensuite ; la correction consiste alors à ajouter un filtre quelque part, ce qui ferme le ticket sans traiter le défaut : et introduit parfois un nouveau bogue fonctionnel en refusant des données légitimes. À l’échelle de l’organisation, l’effet est plus grave : les indicateurs de sécurité deviennent inexploitables. Impossible de savoir si l’on produit des injections, des défauts d’autorisation ou des erreurs de gestion mémoire, donc impossible de choisir une formation, un outil ou une revue qui réduirait vraiment le flux. On mesure une activité, pas un risque, et on investit en conséquence.

🦫 Explication de la marmotte 🍫

Un programme reçoit en permanence des informations de l’extérieur : ce qu’un utilisateur tape, ce qu’un autre programme lui envoie, le contenu d’un fichier. Avant de s’en servir, il devrait vérifier qu’elles ont bien la forme attendue : un âge est un nombre entre 0 et 130, un code postal comporte cinq chiffres, une longueur annoncée ne dépasse pas la place disponible.

Ne pas faire cette vérification est un défaut, que le catalogue CWE appelle CWE-20. Mais ce défaut a une particularité : il est si général qu’il peut décrire presque n’importe quoi. Du coup, les organismes qui publient les failles l’emploient souvent par défaut, quand ils n’ont pas eu le temps d’identifier la véritable cause. C’est l’équivalent, dans un rapport d’accident, de la mention « erreur humaine » : jamais fausse, jamais utile.

L’organisme qui tient le catalogue le dit lui-même : il recommande officiellement de ne pas employer cette catégorie pour classer une faille, parce qu’il existe presque toujours une catégorie plus précise, et parce qu’une telle étiquette rend impossible toute analyse de tendance. Trois autres catégories du classement portent le même avertissement.

Il en résulte un paradoxe qu’il vaut la peine de comprendre : la dix-huitième place de cette catégorie ne mesure pas un danger particulier, elle mesure la quantité de rapports rédigés sans analyse. Et une précision utile pour la pratique : vérifier qu’une information est acceptable ne dispense jamais de la transformer correctement avant usage. Un nom parfaitement valide doit encore être traité avec précaution au moment où on l’affiche dans une page web : ce sont deux précautions différentes, à deux endroits différents.

Pages voisines

La citent

CWE-20 : validation des entrées insuffisante, la classe que le MITRE déconseille

Elle cite

: les deux pages se citent l’une l’autre.

CWE-20 : validation des entrées insuffisante, la classe que le MITRE déconseille

CWE-20 : validation des entrées insuffisante, la classe que le MITRE déconseille

Ce que la classe recouvre exactement

Sa place dans l’arbre, et pourquoi son usage est déconseillé

Pourquoi elle est si haut

Le mécanisme, et où le site le traite

Ce qu’une équipe en fait

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines