← All fixes

Fix it

Logging passwords or tokens, how to fix it

Medium severityCWE-532 (Insertion of Sensitive Information into Log File)
We scanned nearly 2,000 AI-built apps and 1 in 8 shipped a high-severity flaw. Is this one in yours?Scan free →

Logging a whole request body, or the headers, on a route that handles authentication copies passwords, tokens, and API keys straight into your logs in plain text. Those logs flow into aggregators, error trackers, and backups where they persist far longer than intended and are readable by anyone with log access. Log only the non-sensitive fields you actually need.

Why it's a problem

Secrets in logs are secrets in a second, less-guarded place. Log platforms are widely accessible within a team, retained for a long time, and often shipped to third-party services, so a password captured in a log is exposed to everyone and everything that can read those logs. It also turns a minor log leak into a credential breach.

The pattern

app.post("/login", (req, res) => {
  console.log("login attempt", req.body); // logs the password
  // ...
});

The fix

app.post("/login", (req, res) => {
  console.log("login attempt", { email: req.body.email });
  // never log passwords, tokens, or full request bodies
});

Why AI tools write this

Logging the request for debugging is a natural, helpful-looking addition, and dumping req.body is the quickest way to see everything. The assistant is not tracking which fields are secret, so it logs the whole object, password included.

The quick fix

  • Log only the specific non-sensitive fields you need, never the full request body.
  • Redact passwords, tokens, API keys, and authorization headers before logging.
  • Scrub existing logs if secrets were already written to them.

Common questions

What should I log on authentication routes instead of req.body?

Log a minimal non-sensitive set: the timestamp, the route, the email or user id, and the outcome. Never log the password, token, or full request body.

If a secret was already written to logs, how do I handle it?

Treat the secret as compromised, rotate it, and purge the relevant log entries. Most log platforms support deleting or obfuscating specific records and log scrubbing rules to prevent recurrence.

Does this apply to error tracking tools like Sentry?

Yes. Sentry and similar tools collect request context, and if that context includes an auth body, the secret is stored in Sentry's cloud. Use Sentry's before-send hook to scrub sensitive keys before they leave your server.

Want to know if this pattern is already in something you shipped? Scan your live app or a public repo free, no account needed.

Scan my app →

Catch this automatically: scan your GitHub repo · website vulnerability scanner · review every pull request · SAST for AI code · OWASP Top 10 for AI code

Sensitive Data in Logs (Passwords, Tokens), How to Fix It | Prbl