Rule Information
Tags
pythonhardcoded-passworddefault-argumentsecret-in-codecredentialsCWE-259OWASP-A07
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-102 --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
About This Rule
Understanding the vulnerability and how it is detected
Python functions can define default values for parameters. When a parameter name suggests a credential — such as password, passwd, pwd, secret, api_key, token, auth_key, or passphrase — and the default value is a non-empty string literal, the credential is hardcoded into the source code.
Hardcoded credentials are a severe security risk because the source code may be stored in version control, distributed as part of a package, included in error messages, or accessed by developers who should not have the credential. Even if the repository is private, any developer with read access to the code gains the credential, and the credential cannot be rotated without a code change and deployment cycle.
Default function arguments with hardcoded credentials are especially dangerous because callers may rely on the default without realizing it is a real credential, and the credential persists in git history even after it is removed from the current codebase.
Credentials should always be loaded from environment variables, secret management systems, or configuration files outside the source tree. Default values for credential parameters should be None, forcing the caller to explicitly provide a value.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Credential Exposure in Version Control
Hardcoded credentials committed to version control are visible to all developers with repository access. Once committed, the credential remains in git history permanently even if the line is later deleted. Public repository exposure makes the credential available to the entire internet within minutes of the first push.
2
Shared Credentials Across All Deployments
A hardcoded default credential is identical across every deployment — development, staging, and production. Compromise of any single environment or developer machine gives the attacker the production credential without needing to target production specifically.
3
Silent Use of Default Credentials
Callers who do not explicitly pass the credential parameter silently use the hardcoded default. This can result in production systems connecting to databases or external services with a well-known default password that was intended only for local development, with no visible indication of the misconfiguration.
4
Inability to Rotate Credentials
Hardcoded credentials cannot be rotated without a code change and full deployment cycle. During a security incident requiring immediate credential rotation, this dependency on code deployment introduces dangerous delay. Dynamic credential loading from environment variables or secret managers allows rotation without any code change.
How to Fix
Recommended remediation steps
- 1Never use string literals as default values for parameters named password, passwd, pwd, secret, api_key, token, auth, or similar credential names.
- 2Use None as the default value for credential parameters and load the real value from os.environ or a secret manager when None is received.
- 3Require credential parameters explicitly by using keyword-only arguments without defaults, forcing all callers to provide the credential from their own environment.
- 4Audit git history for previously hardcoded credentials and rotate any that were exposed, even if they have since been removed from the codebase.
- 5Use environment-specific configuration files (not committed to version control) or a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects Python function definitions where a parameter whose name matches credential patterns (password, passwd, pwd, secret, api_key, apikey, token, auth_key, passphrase, private_key) has a non-empty string literal as its default value. Both regular function definitions and class method definitions are checked. The rule does not flag parameters whose default is None, an empty string, or a non-string literal.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
CWE Top 25
CWE-259 - Use of Hard-coded Password
OWASP Top 10
A07:2021 - Identification and Authentication Failures
PCI DSS v4.0
Requirement 8.3.6 - Passwords must not be hardcoded in scripts or source files
NIST SP 800-53
IA-5: Authenticator Management — prohibit embedding credentials in code
GDPR Article 32
Technical measures to ensure appropriate security of personal data
References
External resources and documentation
Similar Rules
Explore related security rules for Python
MEDIUM
Insecure File Permissions via os.chmod
os.chmod() or os.fchmod() sets overly permissive file permissions that allow unauthorized read, write, or execute access.
MEDIUM
Logger Credential Leak Risk
Detects logging calls (info, debug, warning, error, critical) that should be audited for accidental credential or secret leakage in log output.
CRITICAL
Django Command Injection via os.system()
User input flows to os.system(), enabling arbitrary OS command execution with the privileges of the Django process.
Frequently Asked Questions
Common questions about Hardcoded Password in Default Function Argument
Default arguments are particularly dangerous because they are silently used when the
caller omits the parameter. A hardcoded credential string in a regular assignment at
least requires explicit code to use it. A default argument means every call that
omits the parameter is using the hardcoded credential, potentially including production
code that was intended to pass a real credential but has a bug.
Even development and test credentials hardcoded in source code are a risk because
developers commonly reuse passwords across environments, and the development credential
may work in staging or production. The correct approach is to use a .env file for
local development (excluded from version control via .gitignore) and have CI inject
test credentials through environment variables.
If backward compatibility requires a default, use a sentinel value like None and
document that None means "read from environment variable DATABASE_PASSWORD". This
preserves the API while moving the actual credential out of source code. Add a
deprecation warning if the credential is not found in the environment, guiding
users toward proper credential management.
Yes. Even encrypted or hashed credential strings in source code are flagged because
the encryption key or hash may be derivable, or the encrypted form itself may be
directly usable for authentication in some protocols. More importantly, the presence
of any credential-like string in source code sets a bad precedent and violates the
principle of separating code from configuration.
If the parameter name is truly a credential name but the default value is intentionally
a test fixture (like "test_password" or "FAKE_PASSWORD_DO_NOT_USE"), rename the
parameter to something that does not match credential patterns (e.g., test_auth_value)
or add a suppression comment. However, ensure the fake credential cannot accidentally
work in any environment before suppressing the finding.
New feature
Get these findings posted directly on your GitHub pull requests
The Hardcoded Password in Default Function Argument rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.