CWE-615, Inclusion of Sensitive Information in Source Code Comments, is about notes that developers leave behind and that end up where users can read them. It hits any web application that ships HTML, JavaScript or templates with comments intact.
How it happens
Comments are useful. Programmers also leave in them filenames related to the web application, old links that were not meant to be browsed, and old code fragments. In server-side templates, an HTML comment is sent to every visitor even though it was written for the team.
<!-- remove soon: old admin panel at /admin_v1/ on build-srv-02 -->
<!-- legacy login: /old/login.php?debug=1 -->
MITRE's observed examples are all disclosure cases. CVE-2007-6197 leaked version numbers and internal hostnames in HTML comments. Another had a CMS place the full server pathname in an HTML comment, and a blog package leaked a real username the same way.
What an attacker gains
The consequence is confidentiality: reading application data. MITRE explains the use. An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study code fragments to reverse engineer the application, which may help develop further attacks.
So the comment itself rarely breaks anything. It shortens the attacker's reconnaissance.
How to find it
MITRE lists automated static analysis (SAST) as a detection method, since it can scan source for suspicious comment content. You can also do a quick manual check:
- View the source of your production pages and search for comment markers.
- Grep your repository for words like password, internal, hostname, admin and internal inside comments.
- Check built JavaScript bundles and templates, not only source files.
Secrets pasted into comments are a related problem. The secrets scanning demo below shows how credentials in code get flagged.
How to fix it
MITRE's mitigation is to remove comments that hold sensitive information about the design or implementation of the application. Some of these comments may be exposed to the user and affect the security posture of the application.
In practice:
- Use server-side comments that never reach the client, or strip comments during the build step.
- Move design notes into a ticket or internal doc.
- Add a review rule that comments never carry hostnames, credentials or paths.
A closer look at where comments leak
Source comments reach users through more routes than raw HTML. Template engines may pass HTML comments straight through. Build tools may leave JavaScript comments in a bundle unless minification removes them. Error pages, generated documentation and sample files can carry notes as well.
The three examples MITRE lists share a theme. None of them involve a secret in the strict sense. A version number, an internal hostname, a server path and a real username are all small facts. Put together they tell an attacker which software to look up, which machine to aim at and which account to try. Reconnaissance is cheap when the application does the talking.
A useful habit is to treat everything the browser receives as public. Before a release, fetch your own pages the way a stranger would and read what comes back. If a line would embarrass you on a billboard, it should not be in a comment.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does a leaked comment give direct access?
Usually not. It lets an attacker map files, find hidden parts of the site and study code, which makes later attacks easier.
What is MITRE's fix?
Remove comments that hold sensitive information about the design or implementation of the application.
