The fix, in one snippet
// vite / webpack production builds strip comments by default
html-minifier --remove-comments index.html
Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now extracts every <!-- ... --> comment from the homepage, ignores Internet Explorer conditional comments and recognisable build banners, and tests the rest against a set of patterns: credential words (password, passwd, secret, api_key, token), developer markers (TODO, FIXME, HACK, XXX), private address ranges and internal hostnames (10.x.x.x, 192.168.x.x, .local, .internal, staging), filesystem paths (/var/www, C:\), SQL fragments, email addresses, and commented-out anchors pointing at admin, backup or old paths. Comments longer than roughly twenty lines are noted as commented-out code. Matches are shown as short excerpts with the pattern that fired. The check is low severity and expects a human to judge the hits; a theme banner containing "TODO" is a false positive, a database password is not.
Why it matters
Everything inside an HTML comment is delivered to every visitor and indexed by anyone who cares to look; only the browser's rendering hides it. The typical damaging cases are mundane: a commented-out link to /admin-old/ that still works, a staging hostname that has weaker protections, a developer's name and email address that become the pretext for a phishing message, or a template where someone pasted a connection string while debugging. Commented-out code shows an attacker how the application is put together and which parameters exist. The OWASP Web Security Testing Guide lists reviewing page content for information leakage as a standard step, and CWE-615 classifies sensitive data in comments as a weakness in its own right. None of this is exploitable alone, which is why it is rated low, but it shortens an attacker's path. The exposed files guide covers the larger cousins of this problem.
How to fix it
Use server-side comment syntax for notes that should never reach the browser; template engines strip these before output:
{# Jinja2 / Django: not rendered #}
{{-- Blade: not rendered --}}
<%# ERB: not rendered %>
{/* JSX: not rendered */}
Strip remaining HTML comments in the build step. html-minifier-terser:
npx html-minifier-terser --remove-comments --collapse-whitespace -o dist/index.html src/index.html
Vite and Next.js production builds remove comments from JSX-rendered output by default; for server-rendered templates, enable the engine's minifier or add a middleware such as express-minify-html. Then search the templates for what should not be there:
grep -rniE '<!--.*(password|secret|api_key|todo|fixme|192\.168|10\.[0-9]+\.)' templates/
Treat any credential found this way as compromised and rotate it. Remove links to retired paths and make sure those paths actually return 404 or require authentication, rather than relying on nobody noticing them.
Where this fits
Sensitive information in HTML comments is check 6 of 10 that the website vulnerability scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits CMS / generator version disclosure (low), where the page announces the CMS or static-site generator it was built with, usually including the version, in a meta tag, header or comment banner. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Sensitive information in HTML comments closes one route in. Immediately below it: Third-party scripts without Subresource Integrity, where scripts or stylesheets are loaded from third-party hosts without an integrity attribute; Inline event handlers and scripts, where the page relies on inline scripts, on* event-handler attributes or javascript: URLs; Password field autocomplete, where password fields on the page either try to disable autocomplete, which browsers ignore and password managers dislike, or lack the autocomplete tokens that let password managers fill and generate credentials safely.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Sensitive information in HTML comments (low severity)
Scanner check id: html-comments-disclosure
The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.