Aller au contenu

CWE-200 : exposition d'information sensible, un impact pris pour une cause

CWE-200 : exposition d’information sensible, un impact pris pour une cause

Section intitulée « CWE-200 : exposition d’information sensible, un impact pris pour une cause »

Vingtième du CWE Top 25 2025. Le libellé officiel est Exposure of Sensitive Information to an Unauthorized Actor, « exposition d’information sensible à un acteur non autorisé ». C’est la troisième entrée du classement dont le MITRE déconseille l’usage, et sa note de mappage est la plus tranchante des trois : la perte de confidentialité est un impact technique, pas une erreur de cause racine.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre, et pourquoi c’est un problème

Section intitulée « Ce que la classe recouvre, et pourquoi c’est un problème »

Le produit expose une information sensible à un acteur qui n’est pas explicitement autorisé à y avoir accès.

Le MITRE explique son avertissement par un chiffre qui règle la question : depuis la version 4.9 du catalogue, plus de quatre cents entrées peuvent conduire à une perte de confidentialité. Classer une vulnérabilité sous CWE-200 revient donc à dire qu’elle fait partie des quatre cents, ce qui n’oriente aucune correction. Le catalogue conclut par une consigne : « si une erreur provoque la divulgation d’une information, utilisez l’identifiant CWE de cette erreur ».

La distinction entre cause et impact est l’un des apports les plus utiles du catalogue, et c’est ici qu’elle se voit le mieux. Une injection SQL expose des informations sensibles ; une traversée de chemin expose des informations sensibles ; une lecture hors limites expose des informations sensibles. Aucune des trois ne se corrige de la même façon, et les trois peuvent être déclarées sous CWE-200 par qui s’arrête au résultat.

Sa place dans l’arbre, et les filles qui servent vraiment

Section intitulée « Sa place dans l’arbre, et les filles qui servent vraiment »

CWE-200 est une classe, fille de CWE-668, « exposition d’une ressource à la mauvaise sphère » : le même parent que le téléversement de fichier dangereux, ce qui éclaire la logique du catalogue : dans les deux cas, quelque chose franchit une frontière de confiance.

Sous elle, en revanche, vivent des entrées parfaitement utilisables, qui désignent chacune une erreur précise. Les cinq qu’on rencontre le plus :

  • CWE-532, l’insertion d’information sensible dans un fichier de journal, le secret qui finit dans les traces, cas de loin le plus fréquent ;
  • CWE-209, la génération d’un message d’erreur contenant une information sensible : la trace d’exécution complète rendue au client, la requête échouée affichée avec ses paramètres ;
  • CWE-215, l’insertion d’information sensible dans des traces de débogage, et CWE-1295, les messages de débogage qui révèlent plus que nécessaire, le mode diagnostic resté actif en production ;
  • CWE-359, l’exposition d’informations personnelles privées, qui fait le lien avec les obligations réglementaires ;
  • CWE-203, l’écart observable : le système se comporte différemment selon un secret, et cette différence suffit à le deviner. C’est la famille des canaux auxiliaires, où la divulgation ne passe par aucune donnée transmise.

Choisir l’une de ces entrées plutôt que la classe parente, c’est la différence entre un ticket qui dit « des informations fuient » et un ticket qui dit « le niveau de journalisation du module de paiement écrit les jetons en clair ».

Parce qu’elle sert de fourre-tout aux divulgations. Un scanner qui constate qu’une page renvoie la version du serveur, une trace d’exécution ou un chemin interne signale une exposition d’information sensible, et c’est exact. Ces signalements sont innombrables et peu graves, ce qui explique une fréquence élevée pour une gravité modérée.

Parce que la journalisation moderne est centralisée. Plus les journaux sont collectés, enrichis et conservés, plus un secret qui y entre se propage et se conserve longtemps. C’est l’entrée CWE-532 qui le dit, et c’est l’un des rares défauts dont la gravité augmente avec la qualité de l’infrastructure.

Parce que les assistants d’intelligence artificielle ont ouvert un nouveau chemin. Un secret collé dans un prompt quitte l’organisation et entre dans un service tiers, avec les conséquences que le site décrit. Le catalogue n’avait pas prévu ce vecteur ; la classe le couvre sans difficulté.

Le site traite les causes, ce qui est exactement ce que cette page recommande de faire. Pour les secrets dans le code, prévenir les secrets codés en dur dans Git et les secrets dans les dépôts ; pour les secrets envoyés à un service tiers, la fuite de secrets dans les prompts et la rétention des données envoyées à une API d’IA.

Pour la journalisation, qui est le vecteur principal, l’architecture de journalisation d’audit immuable pose la question dans le bon sens : ce qu’on conserve, pour qui, et pour combien de temps. Et pour l’exemple historique le plus commenté d’une collecte involontaire devenue incident juridique, Google Street View et les trames Wi-Fi en clair.

Côté réglementaire, l’exposition de données personnelles n’est pas qu’un défaut technique : les exigences d’architecture du RGPD et les délais de notification d’incident décrivent ce que l’organisation doit faire des heures qui suivent la découverte.

Remplacer l’étiquette par la cause. Devant un rapport citant CWE-200, chercher laquelle des entrées filles s’applique. C’est la seule façon d’obtenir un ticket actionnable, et c’est aussi ce que demande le catalogue.

Filtrer à l’écriture des journaux, pas à la lecture. Une liste de champs à ne jamais journaliser, appliquée dans la bibliothèque de journalisation, protège tous les modules. Un filtrage dans l’outil d’analyse arrive après la conservation, donc trop tard.

Couper la verbosité en production, et traiter la trace d’exécution comme une donnée interne : un identifiant d’erreur pour le client, les détails dans le journal du serveur. C’est le contrôle qui ferme CWE-209 et CWE-1295 d’un seul geste.

Une équipe qui confond l’impact et la cause produit un suivi de vulnérabilités où tout ce qui fuit se range au même endroit, de la version du serveur affichée en pied de page au jeton d’administration écrit dans les journaux. Les deux lignes se ressemblent dans le tableau, la première est traitée parce qu’elle est facile, la seconde attend. Le coût se paie au moment de la réponse à incident : quand une fuite est constatée, la question est « par où ? », et un historique qui ne contient que des étiquettes d’impact n’apporte aucune réponse. Il faut alors reprendre l’analyse à zéro sur un système en production, pendant que l’horloge réglementaire tourne : car si les données exposées sont personnelles, la notification se compte en heures, et l’organisation doit décrire une cause qu’elle n’a jamais caractérisée.

Quand une information confidentielle se retrouve entre des mains qui ne devaient pas l’avoir, on parle d’exposition d’information sensible. C’est ce que décrit l’entrée CWE-200 du catalogue des défauts logiciels.

Mais il y a un problème avec cette entrée, et l’organisme qui tient le catalogue le dit lui-même : elle ne décrit pas une erreur, elle décrit une conséquence. Plus de quatre cents défauts différents, dans le même catalogue, peuvent aboutir à une fuite d’information. Écrire qu’une faille relève de CWE-200 revient donc à écrire qu’un cambriolage a eu lieu, sans préciser si la porte était ouverte, la serrure forcée ou le code connu du voisin.

Les entrées rangées sous celle-ci sont en revanche très utiles, parce qu’elles nomment des erreurs concrètes. La plus fréquente est l’inscription de secrets dans les journaux techniques : un mot de passe, un jeton d’accès ou un numéro de carte enregistré dans les fichiers de traces, qui sont ensuite copiés, centralisés et conservés des mois. Vient ensuite le message d’erreur trop bavard, qui renvoie au visiteur le détail interne du programme. Puis le mode diagnostic resté actif après la mise en service.

La leçon pratique tient en une question. Devant un rapport qui annonce une « exposition d’information sensible », il faut demander : par quel mécanisme ? Sans cette réponse, on ne peut rien corriger : et le jour où une fuite réelle se produit, on ne peut pas non plus dire ce qui est sorti, ni par où, ce qui est pourtant la première chose que demandent les personnes concernées et l’autorité qui doit en être informée.

À lire aussi

Pages voisines

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