Rule Information
Tags
pythonloggingcredentialsinformation-disclosureauditCWE-532OWASP-A09
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-LANG-SEC-105 --project .1
2
3
4
5
6
7
8
9
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
About This Rule
Understanding the vulnerability and how it is detected
This rule flags calls to logging.info(), logging.debug(), logging.warning(), logging.error(), logging.critical(), logging.exception(), and logging.log() as audit items. Log statements are a common vector for accidentally exposing passwords, API keys, session tokens, database connection strings, and other secrets.
Developers often add verbose logging during debugging and forget to remove it before shipping. A single logging.debug(f"Connecting with password={password}") can expose credentials to anyone with access to log files, log aggregation services, or error tracking tools.
The rule operates at audit level because most logging calls are harmless. Review each flagged call to ensure no sensitive data appears in the format string or arguments.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Credential Exposure in Log Files
Passwords, API keys, and tokens logged in plaintext persist in log files, log aggregation services (ELK, Datadog, Splunk), and error tracking tools (Sentry). Anyone with access to logs can extract credentials without accessing the application database or config.
2
Compliance Violations
PCI DSS explicitly prohibits logging authentication credentials (Requirement 8.5). GDPR and HIPAA require protecting personal data in all storage locations including logs. A single logged password can result in a compliance finding.
3
Lateral Movement via Log Access
In cloud environments, log storage (CloudWatch, GCP Logging, Azure Monitor) is often accessible to broader teams than application secrets. A credential in a log file has a larger blast radius than one in a secrets manager.
How to Fix
Recommended remediation steps
- 1Never log passwords, API keys, session tokens, or database connection strings
- 2Use structured logging with explicit field names so sensitive fields can be filtered by log pipelines
- 3Implement a log redaction layer that scrubs known secret patterns (Bearer tokens, AWS keys, passwords) before output
- 4Set production log level to INFO or WARNING to prevent debug-level credential logs from reaching production
- 5Review logging statements in code review with the same scrutiny as security-sensitive code
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule matches all standard logging method calls via the QueryType pattern LoggingModule.method("info", "debug", "warning", "error", "critical", "exception", "log"). It operates as an audit rule that flags all logging calls for manual review of the message content.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A09:2021 - Security Logging and Monitoring Failures
PCI DSS v4.0
Requirement 8.5 - do not log authentication credentials
GDPR
Article 32 - appropriate technical measures to protect personal data
NIST SP 800-53
AU-3: Content of Audit Records
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Hardcoded Password in Default Function Argument
A function defines a default argument whose name suggests a password or secret but whose value is a hardcoded string literal.
HIGH
logging.config.listen() Eval Risk
Detects logging.config.listen() which opens a socket that accepts and executes arbitrary logging configuration, enabling remote code execution.
Frequently Asked Questions
Common questions about Logger Credential Leak Risk
No. This is an audit rule. Most logging calls are harmless. It flags all
logging calls so you can review them for sensitive data. If the log message
only contains operational information (request IDs, timing, status codes),
it's fine.
Use structured logging with explicit fields. Never interpolate secrets
into log messages. Implement a log filter that redacts patterns like
password=, Bearer, sk-, AKIA (AWS keys), etc.
Stack traces can expose local variable values, including secrets passed
as function arguments. Use logging.exception() carefully and consider a
custom exception handler that redacts sensitive variables.
Logging credential exposure requires access to log files to exploit.
It's not directly exploitable from the network. However, in environments
with centralized logging (which is most production systems), the blast
radius can be significant.
Run: pathfinder ci --ruleset python/lang --project .
New feature
Get these findings posted directly on your GitHub pull requests
The Logger Credential Leak Risk rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.