What Attackers Find in View Source: Information Disclosure in Page Comments

Every web page you load is delivered to your browser as raw HTML. The browser then decides what to show you, but it does not throw the rest away - the entire document, including parts the browser deliberately hides, is sitting in plain text on your machine. That is exactly what an attacker reads when they open View Source or inspect the response in their developer tools. The polished, rendered page is only half the story; the source is the whole story.

Sensitive information disclosure happens when a developer leaves something in that source that was never meant for outside eyes. HTML comments are the classic culprit, because comments are invisible on the rendered page yet ship to every visitor verbatim. Developers treat them like private sticky notes - reminders, debug hints, half-finished TODOs, references to internal tools and endpoints - forgetting that the comment travels with the page to the public internet. The same applies to hidden form fields, stale URLs, version strings, and leftover scaffolding.

To an attacker, reconnaissance is mostly about collecting these small giveaways. None of them is an exploit on its own, but each one removes guesswork: it tells the attacker what exists, where to look next, and which doors might be unlocked. A page that renders perfectly can still be quietly leaking the exact information that turns a blind probe into a targeted attack.

• Assuming that because something is invisible in the rendered page it is also invisible to attackers - comments and hidden elements ship to the browser in full and are trivial to read.
• Only scanning the visible UI (headings, links, buttons) and ignoring the non-rendered markup where the real leak usually hides.
• Treating HTML comments as private developer notes, when they are public the moment the page is served.
• Believing minification or a production build automatically strips comments - it often does not unless it is explicitly configured to.

The reliable fix is to make sure internal notes never reach the browser in the first place. Strip developer comments and debug markup at build time, and keep implementation reminders in your issue tracker or code comments on the server side - never in the HTML that ships to clients. Treat the rendered page and its source as one and the same public artefact when deciding what is safe to include.

• Configure your build or template engine to remove HTML comments and debug output from production responses.
• Review the actual served source - not just the rendered page - before release, and add a check for leftover TODOs, internal URLs, and debug flags.
• Never rely on something being unlinked or hidden as a security control; if a route exists, protect it with real authentication and authorisation rather than secrecy.