The Comment Leak: Finding a Debug Endpoint Hidden in HTML Source
Le défi
Ce tableau de bord de facturation a l'air propre, mais un développeur a laissé une note dans le HTML qui n'est jamais retirée avant la mise en production. Ouvrez le code source, lisez le commentaire, et soumettez l'endpoint de debug qu'il mentionne.
Ce que tu vas apprendre
- Open and read a page's View source rather than trusting the rendered output
- Recognise that HTML comments are delivered to the client and never confidential
- Spot a developer TODO note that leaks an internal endpoint and a key
- Extract an exact URL path from free-form comment text
- Explain why debug routes and notes must be stripped before production
Compétences testées
Prérequis
- Knowing how to open View source in a browser
- Basic familiarity with URL paths and query strings
Comment ça marche
When a browser renders a page, it shows you the visual result - headings, text, buttons. It does not show you everything that arrived over the wire. HTML comments, written as <!-- ... -->, are stripped from the rendered view but are sent verbatim to every visitor. Anyone can read them by choosing View source or opening the network response. They are, for security purposes, completely public.
Developers routinely leave comments as reminders: a TODO to remove a debug route, a note about an unfinished feature, sometimes even a credential. In this challenge the comment reads TODO remove /api/v2/debug?key=DEV-9931 before release - no auth on this route yet. That single line tells an attacker three things: an undocumented endpoint exists, where it lives, and that it has no authentication, plus it even includes a working key. None of it is visible on the page, so a developer might assume it is hidden - but it ships to everyone.
The fix is not to hide the comment better. It is to never put sensitive notes in client-delivered markup at all. Anything the server sends to the browser - HTML, comments, hidden fields, JavaScript - should be treated as fully readable by the user, because it is.
Erreurs fréquentes
- Trusting the rendered page. Looking only at what the browser paints and assuming nothing else was sent. The interesting data is in the source, not the view.
- Skipping the comments. Scanning the source for visible elements but ignoring
<!-- -->blocks, which is exactly where the leak lives here. - Submitting the wrong fragment. Typing the key alone (
DEV-9931) instead of the endpoint path that was asked for. - Assuming a hidden route is a safe route. Treating "not linked in the UI" as "not reachable". The comment proves the opposite.
Comment s'en protéger
Treat the entire HTML response as public and keep secrets and internal references out of it entirely. Stripping comments at build time and removing debug routes before release is cheap insurance against this whole class of leak.
- Strip HTML comments from production builds with your bundler or templating engine.
- Never write credentials, keys, internal URLs, or unfinished-feature notes into markup, even in comments.
- Remove or authenticate debug and internal endpoints rather than relying on them being unlinked.
- Add a review or CI check that fails the build when
TODO, keys, or internal paths appear in shipped HTML.