Problem
The A09-SENSITIVE-LOG rule flags any console.log|warn|error or logger.* call that contains words like password, token, secret, api_key, bearer, etc. This produces false positives when the log is a configuration/status message (e.g., "API key not configured") rather than an actual secret value being logged.
Reproduction
1. Configuration missing message
const apiKey = process.env.RESEND_API_KEY?.trim();
if (!apiKey) {
console.warn("[partner-invites] No RESEND_API_KEY — skipping send");
// ↑ flagged: "Logging statement appears to include API key"
}2. Script diagnostic output
const apiKey = process.env.MSGRUSH_API_KEY?.trim();
if (!apiKey) {
console.error("MSGRUSH_API_KEY not set in env. Set it in apps/web/.env.local before running.");
// ↑ flagged: "Logging statement appears to include API key"
}3. Admin tool output
console.log(` ${bold("Has Password:")} ${Boolean(line.xmppPasswordEnc)}`);
// ↑ flagged: "Logging statement appears to include password"In our production monorepo, this pattern produces 30+ high-severity findings, nearly all from dev/ops scripts that log configuration status, not actual secrets.
Current mitigation attempts
The rule already skips lines that:
- Check/validate (
if, .length, ===, !==, typeof, undefined, null, missing)
- Redact values (
redact, mask, sanitize, ***, xxx, REDACTED)
But these don't catch configuration/status messages where the env var NAME is mentioned but its VALUE is not present.
Proposed Solutions
Solution A: Distinguish "env var name" vs "env var value"
When a log line contains an env var name (e.g., RESEND_API_KEY) but does NOT contain an actual secret value (we can look at the surrounding context for process.env.XXX extraction), it's a status message, not a leak.
Solution B: Skip lines that only reference env var names
If a log line is entirely a message about configuration state (contains not set, not configured, missing, required, skipping, before running, along with an env var name), skip it.
Solution C: Configurable scope for the rule
Allow consumers to scope A09-SENSITIVE-LOG to specific directories or file patterns. E.g., ignore scripts/ and **/cli/** directories where diagnostic logging is expected.
Preference
Solution B has the best signal/noise ratio — it's a targeted heuristic for the most common false positive class. Solution A is more robust but harder to implement accurately without data flow analysis.
Reported from Dial-WTF/x402-dial production rollout — PR #120
Problem
The
A09-SENSITIVE-LOGrule flags anyconsole.log|warn|errororlogger.*call that contains words likepassword,token,secret,api_key,bearer, etc. This produces false positives when the log is a configuration/status message (e.g., "API key not configured") rather than an actual secret value being logged.Reproduction
1. Configuration missing message
2. Script diagnostic output
3. Admin tool output
In our production monorepo, this pattern produces 30+ high-severity findings, nearly all from dev/ops scripts that log configuration status, not actual secrets.
Current mitigation attempts
The rule already skips lines that:
if,.length,===,!==,typeof,undefined,null,missing)redact,mask,sanitize,***,xxx,REDACTED)But these don't catch configuration/status messages where the env var NAME is mentioned but its VALUE is not present.
Proposed Solutions
Solution A: Distinguish "env var name" vs "env var value"
When a log line contains an env var name (e.g.,
RESEND_API_KEY) but does NOT contain an actual secret value (we can look at the surrounding context forprocess.env.XXXextraction), it's a status message, not a leak.Solution B: Skip lines that only reference env var names
If a log line is entirely a message about configuration state (contains
not set,not configured,missing,required,skipping,before running, along with an env var name), skip it.Solution C: Configurable scope for the rule
Allow consumers to scope
A09-SENSITIVE-LOGto specific directories or file patterns. E.g., ignorescripts/and**/cli/**directories where diagnostic logging is expected.Preference
Solution B has the best signal/noise ratio — it's a targeted heuristic for the most common false positive class. Solution A is more robust but harder to implement accurately without data flow analysis.
Reported from Dial-WTF/x402-dial production rollout — PR #120