Ce que les attaquants trouvent en affichant le code source : la fuite d'informations dans les commentaires de page

Chaque page web que vous chargez est envoyée à votre navigateur sous forme de HTML brut. Le navigateur décide ensuite de ce qu'il va afficher, mais il ne jette pas le reste : le document entier, y compris les parties que le navigateur cache volontairement, se trouve en texte clair sur votre machine. C'est exactement ce qu'un attaquant lit lorsqu'il ouvre l'affichage du code source ou inspecte la réponse dans ses outils de développement. La page bien présentée que l'on voit à l'écran n'est que la moitié de l'histoire ; le code source, lui, raconte tout.

La fuite d'informations sensibles se produit lorsqu'un développeur laisse dans ce code source quelque chose qui n'était pas destiné à être vu de l'extérieur. Les commentaires HTML en sont le coupable classique, car ils sont invisibles sur la page rendue mais envoyés mot pour mot à chaque visiteur. Les développeurs les traitent comme des post-it privés : rappels, indices de debug, TODO inachevés, références à des outils et endpoints internes, en oubliant que le commentaire voyage avec la page jusque sur l'internet public. Il en va de même pour les champs de formulaire cachés, les URL obsolètes, les chaînes de version et les restes de code d'échafaudage.

Pour un attaquant, la reconnaissance consiste surtout à collecter ces petits indices révélateurs. Aucun d'eux n'est un exploit en soi, mais chacun réduit la part de tâtonnement : il indique à l'attaquant ce qui existe, où chercher ensuite, et quelles portes pourraient être déverrouillées. Une page qui s'affiche parfaitement peut malgré tout fuiter discrètement l'information exacte qui transforme un sondage à l'aveugle en attaque ciblée.

• Supposer que ce qui est invisible sur la page rendue l'est aussi pour les attaquants : les commentaires et les éléments cachés sont envoyés en entier au navigateur et se lisent sans effort.
• Se contenter d'examiner l'UI visible (titres, liens, boutons) en ignorant le code non rendu, là où la vraie fuite se cache généralement.
• Considérer les commentaires HTML comme des notes privées de développeur, alors qu'ils deviennent publics dès que la page est servie.
• Croire que la minification ou un build de production supprime automatiquement les commentaires : ce n'est souvent pas le cas sauf si c'est explicitement configuré.

La solution fiable consiste à s'assurer que les notes internes n'atteignent jamais le navigateur. Retirez les commentaires de développeur et le code de debug au moment du build, et conservez les rappels d'implémentation dans votre outil de suivi de tickets ou dans des commentaires de code côté serveur, jamais dans le HTML envoyé aux clients. Considérez la page rendue et son code source comme un seul et même artefact public au moment de décider ce qu'il est sûr d'y inclure.

• Configurez votre build ou votre moteur de templates pour retirer les commentaires HTML et les sorties de debug des réponses de production.
• Relisez le code source réellement servi, pas seulement la page rendue, avant chaque mise en production, et ajoutez une vérification des TODO oubliés, des URL internes et des flags de debug.
• Ne comptez jamais sur le simple fait qu'une route ne soit pas liée ou soit cachée comme mesure de sécurité ; si une route existe, protégez-la par une vraie authentification et une vraie autorisation plutôt que par le secret.