CWE-540 Sensitive Information in Source Code: Real Cases and Fixes

CWE-540, Inclusion of Sensitive Information in Source Code, is about code that holds secrets and is visible to people who should not see them. MITRE says source code on a web server or repository often contains sensitive information and should generally not be accessible to users.

It reaches well beyond one language. Web pages count too, because the HTML and JavaScript you send to a browser is source code the visitor can read.

How it happens

There are a few common routes.

Server-side source is exposed. MITRE's example is Perl: obtaining the source of a script lets an attacker understand its logic and pull out useful information such as code bugs, logins and passwords. A script left in a reachable directory is a document anyone can download.

Secrets are baked into client-side code. JavaScript and HTML are delivered to every visitor. Anything inside is public.

Comments and metadata carry internals. Developers leave notes in markup that were meant for the team.

MITRE lists three observed cases that show each route:

• CVE-2022-25512: a server for the Team Awareness Kit application included sensitive tokens in the JavaScript source code (Gold entry).
• CVE-2022-24867: an LDAP password might be visible in the HTML code of a rendered page in an IT asset management tool (Gold entry).
• CVE-2007-6197: version numbers and internal hostnames were leaked in HTML comments (Gold entry).

A short vulnerable pattern:

// Vulnerable: shipped to every browser
const API_TOKEN = "live-token-goes-here";
fetch("/internal/report", { headers: { Authorization: "Bearer " + API_TOKEN } });

The fix moves the credential to the server, which calls the protected service on the user's behalf:

// Browser code: no secret at all
fetch("/api/report", { credentials: "include" });

On the server, read the token from the environment or a secrets store and attach it there.

What an attacker gains

MITRE lists a confidentiality impact: reading application data. With a token, they can call the service that token protects. With a password in rendered HTML, they hold a working login. With internal hostnames and version numbers, they get a map of your network and software to aim at.

How to find it

• View the source of your own pages and bundles. Search for password, token, key, secret and internal domain names.
• Search the repository history, not just the current tree. A removed secret can still sit in old commits.
• Run a secrets scan across code and built artifacts. Check the production bundle, because build steps can inject values.
• Review HTML comments in templates before release.
• MITRE notes static analysis can find some instances of this weakness.

You can also scan your dependency manifest in the browser, with no login, at the free Gold scanner. The file stays on your machine and the limit is 100 dependencies. It looks at packages rather than secrets, but it fits the same habit of checking what you ship.

How to fix it

MITRE's recommendation is to remove the script from the web server and move it to a location not accessible from the Internet. Put in steps:

1. Keep server-side code outside any directory the web server serves.
2. Keep secrets out of source files entirely. Use environment variables or a secrets manager.
3. Never place credentials in JavaScript or HTML sent to a browser. Make the server hold them.
4. Strip internal comments, hostnames and version details from templates and builds.
5. If a secret ever reached a page or repository, treat it as exposed. Rotate it.
6. Add a secrets check to your pull request pipeline so the next one is caught early.

Try it yourself

This demo shows a secrets scan on a repository.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE CWE-540