Safeguard
Application Security•

CWE-215 Sensitive Information in Debugging Code

Debug output that prints passwords is fine on a laptop and a leak in production. CWE-215, how to find leftover debug code, and how to remove it.

Safeguard Security Team
2 min read

CWE-215, Insertion of Sensitive Information Into Debugging Code, is what happens when a product puts sensitive data into debugging code and that code is still active in production.

While debugging, a programmer often needs detailed output. That is reasonable. The weakness appears when the same detail keeps flowing after release.

How it happens

A developer adds a print statement to see why authentication fails, includes the password or token, and never removes it. Or a debug flag defaults to on. MITRE's observed examples:

  • CVE-2004-2268: a password exposed in debug information.
  • CVE-2002-0918: a CGI script includes sensitive information in debug messages when an error is triggered.
  • CVE-2003-1078: an FTP client with the debug option enabled shows the password on screen.
# Vulnerable: debug line left behind
def login(user, password):
    print(f"DEBUG login attempt user={user} password={password}")
    ...

What an attacker gains

MITRE lists confidentiality: reading application data. Whatever the debug output includes goes to whoever can see the screen, response or log.

How to find it

MITRE points to static analysis. SAST tools analyze source or compiled code without running it, building a model of data flow, and can find some instances of this weakness.

By hand, search for print, console.log, var_dump and debug-level log calls near variables named password, token, secret or key, and check which debug flags are on in each environment.

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

How to fix it

MITRE's mitigations:

  1. Remove debug statements that could execute. Make sure all debug information is gone before release.
  2. Compartmentalize. Define trust boundaries, keep sensitive data inside them, and use least privilege.

A simple pattern is to never log secret values at all, even at debug level:

log.debug("login attempt user=%s", user)   # no password

Quick check

Is a debug log line harmless if logs are private?

Only as long as they stay private. Passwords in logs spread to backups, tickets and tools. Leave secrets out.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.