Information Disclosure

Pourquoi c'est important

Le serveur vous en dit constamment plus que ce que le navigateur affiche. Un frontend moderne reçoit une erreur JSON complète et n'affiche que le champ message convivial, en laissant tomber silencieusement le stack, l'exception de base de données et le détail de débogage. Lisez la réponse brute dans un proxy d'interception comme Burp Suite et ce détail caché devient de la reconnaissance gratuite.

La divulgation d'information est l'une des découvertes les plus courantes en bug bounty et la discrète première étape de nombreuses violations réelles, parce qu'elle convertit les conjectures en attaque ciblée. Elle est cataloguée sous CWE-200 et sous-tend la phase de reconnaissance de presque chaque évaluation web.

Sources courantes

• Traces de pile : font fuiter le langage, le framework, les chemins de fichiers et les numéros de ligne, souvent à partir d'une exception non gérée.
• Erreurs de base de données : font fuiter le moteur, le nom de la base, les tables et les colonnes, le tremplin parfait pour l'injection SQL.
• En-têtes verbeux : les bannières Server et X-Powered-By révèlent le logiciel et les versions qu'un attaquant peut faire correspondre à des CVE connues.
• API qui en renvoient trop : des points de terminaison qui renvoient plus de champs que l'interface n'en affiche, incluant parfois les données d'autres utilisateurs ou des drapeaux internes.
• Source maps, commentaires et points de terminaison de débogage : exposent la logique interne, les routes cachées et, à l'occasion, des secrets codés en dur.

Un exemple concret

Un formulaire de connexion affiche le message générique "the email or password provided is incorrect". La même requête dans un proxy renvoie un 401 dont le JSON porte aussi un champ stack pointant vers /home/app/node_modules/payload/dist/auth/operations/login.js. En une seule connexion échouée, le testeur sait désormais que le runtime est Node.js, que le framework est Payload, et les chemins serveur exacts, rien de tout cela n'ayant été affiché par le navigateur. Ce détail guide chaque test qui suit.

Comment les attaquants s'en servent

Un nom de framework fuité pointe vers des vulnérabilités connues. Un chemin de fichier fuité permet à un attaquant de deviner d'autres points de terminaison. Un nom de table et de colonne fuité transforme une tentative d'injection aveugle en un UNION SELECT précis. La divulgation elle-même peut sembler inoffensive, mais elle supprime l'incertitude qui protège la plupart des cibles, ce qui explique pourquoi les équipes de triage la récompensent encore même lorsque aucune exploitation supplémentaire n'est démontrée.

Comment la tester

Déclenchez des erreurs à dessein et lisez la réponse brute. Soumettez des types inattendus, supprimez des champs requis, envoyez du JSON malformé, demandez des ressources absentes, et comparez une réponse 500 à un 200 normal. Inspectez chaque en-tête, cherchez les champs que l'interface n'affiche jamais, et vérifiez /.well-known/, les source maps et les réponses d'API verbeuses. L'habitude qui compte est de lire la réponse que le serveur a réellement envoyée, pas la page que le navigateur a dessinée.

Prévention

Affichez aux utilisateurs des erreurs génériques et gardez le détail dans les journaux côté serveur. Désactivez la sortie de débogage en production, retirez les bannières de version, et assurez-vous que les API ne renvoient que les champs autorisés via des modèles de réponse explicites. Surtout, testez votre propre application à travers un proxy pour voir les réponses brutes que les navigateurs de vos utilisateurs masquent.