The Comment Leak: Finding a Debug Endpoint Hidden in HTML Source
O desafio
Este painel de faturamento parece limpo, mas um desenvolvedor deixou uma anotação no HTML que nunca é removida antes de publicar. Abra o código-fonte, leia o comentário e envie o endpoint de debug que ele menciona.
O que você vai aprender
- 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
Habilidades testadas
Pré-requisitos
- Knowing how to open View source in a browser
- Basic familiarity with URL paths and query strings
Como funciona
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.
Erros comuns
- 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.
Como se proteger
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.