Rule Information
Tags
pythonssltlsverify-falsecert-validationmitmCWE-295OWASP-A02
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-053 --project .1
2
3
4
5
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
About This Rule
Understanding the vulnerability and how it is detected
Setting verify=False in HTTP library calls (requests, httpx, aiohttp) or setting ssl.CERT_NONE on an SSL context explicitly disables TLS certificate verification. Without certificate verification, TLS connections are encrypted but not authenticated, enabling man-in-the-middle attacks.
This parameter is commonly added as a quick fix for certificate errors in development environments and accidentally deployed to production, or deliberately disabled in production to work around certificate issues instead of fixing the underlying problem.
verify=False in the requests library or CERT_NONE in ssl.SSLContext both have the same effect: the server can present any certificate and the client will accept it, allowing network attackers to intercept and modify all traffic.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Man-in-the-Middle Attack
With verify=False, an attacker on the network can present any TLS certificate and intercept the connection. The client accepts the fraudulent certificate and transmits data (credentials, tokens, private data) to the attacker's server.
2
Authentication Bypass
In mutual TLS (mTLS) or certificate-pinning scenarios, disabling verification bypasses the server authentication entirely. An attacker can impersonate any server and receive authentication tokens or session data intended for the legitimate server.
3
Silent Production Deployment of Debug Setting
verify=False is a common debugging shortcut that is frequently committed and deployed to production accidentally. Unlike obvious code changes, it is a single parameter that may be overlooked in code review.
4
Data Integrity Failure
MITM attackers can modify API responses in transit, injecting malicious data, altering financial values, or replacing file downloads with malicious content. The client has no way to detect the tampering without valid certificate verification.
How to Fix
Recommended remediation steps
- 1Remove verify=False from all requests, httpx, and aiohttp calls; certificate verification is enabled by default and should remain so.
- 2If connecting to a server with a private or corporate CA certificate, use verify='/path/to/ca-bundle.crt' instead of verify=False.
- 3Fix the underlying certificate error (expired, wrong hostname, untrusted CA) rather than disabling verification as a workaround.
- 4Use ssl.create_default_context() which sets CERT_REQUIRED by default, instead of manually configuring ssl.CERT_NONE.
- 5Add linting rules to your CI/CD pipeline to prevent verify=False from being merged into main branches.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects calls to requests.get(), requests.post(), requests.put(), requests.delete(), requests.patch(), requests.head(), and requests.Session() calls with verify=False, and ssl.SSLContext configurations that set verify_mode = ssl.CERT_NONE or check_hostname = False.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
PCI DSS v4.0
Requirement 4.2.1 - Use strong cryptography for sensitive data transmission (certificate validation required)
OWASP Top 10
A02:2021 - Cryptographic Failures
NIST SP 800-52 Revision 2
Certificate validation required for all TLS connections
HIPAA Security Rule
45 CFR 164.312(e) - Technical safeguards for data in transit
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Unverified SSL Context Created
ssl._create_unverified_context() disables certificate verification entirely, making TLS connections vulnerable to man-in-the-middle attacks.
HIGH
Weak SSL/TLS Protocol Version
SSLContext configured with SSLv2, SSLv3, TLSv1.0, or TLSv1.1 uses deprecated protocols with known vulnerabilities. Use TLS 1.2 or TLS 1.3.
MEDIUM
Deprecated ssl.wrap_socket() Usage
ssl.wrap_socket() is deprecated since Python 3.7 and should be replaced with SSLContext.wrap_socket() for proper TLS configuration.
Frequently Asked Questions
Common questions about Certificate Validation Disabled (verify=False)
In unit tests that mock network calls, verify=False is never reached in practice.
In integration tests against a local test server, use a test CA certificate with
verify='/path/to/test-ca.crt' or use mkcert to generate locally trusted certificates.
This ensures tests validate the same TLS configuration as production and prevents
test code with verify=False from being accidentally used in production.
The requests library includes it as an escape hatch for development and for connecting
to services in environments where proper certificate deployment is not possible.
It explicitly warns in documentation that disabling verification is a security risk.
The existence of the option is not an endorsement of its use in production.
The error indicates a real certificate problem. Common causes and fixes: (1) Expired
certificate: renew it. (2) Hostname mismatch: use the correct hostname or update the
certificate SAN. (3) Self-signed certificate: pass verify='/path/to/selfsigned.crt'.
(4) Corporate proxy MITM: add verify='/path/to/corporate-ca.crt'. (5) Missing
intermediate CA: install the full certificate chain on the server.
Yes. Setting check_hostname = False on an SSLContext disables hostname verification,
which is also a critical MITM enabler. Combined with CERT_REQUIRED, an attacker can
present any valid certificate for any hostname. Both patterns are detected.
Code that suppresses urllib3.exceptions.InsecureRequestWarning using
urllib3.disable_warnings() is also a sign of disabled certificate verification.
This pattern often accompanies verify=False calls and should be audited as part
of the same finding.
For localhost connections to services you control, the MITM risk is low. However,
even localhost TLS should use proper certificates for consistency with production
configuration. Use mkcert to generate locally trusted localhost certificates instead
of disabling verification.
New feature
Get these findings posted directly on your GitHub pull requests
The Certificate Validation Disabled (verify=False) rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.