This vulnerability makes it possible that an encrypted communication is intercepted.
Transport Layer Security (TLS) provides secure communication between systems over the internet by encrypting the data sent between them. Certificate validation adds an extra layer of trust and security to this process to ensure that a system is indeed the one it claims to be.
When certificate validation is disabled, the client skips a critical security check. This creates an opportunity for attackers to pose as a trusted entity and intercept, manipulate, or steal the data being transmitted.
Establishing trust in a secure way is a non-trivial task. When you disable certificate validation, you are removing a key mechanism designed to build this trust in internet communication, opening your system up to a number of potential threats.
If a system does not validate certificates, it cannot confirm the identity of the other party involved in the communication. An attacker can exploit this by creating a fake server and masquerading as a legitimate one. For example, they might set up a server that looks like your bank’s server, tricking your system into thinking it is communicating with the bank. This scenario, called identity spoofing, allows the attacker to collect any data your system sends to them, potentially leading to significant data breaches.
When TLS certificate validation is disabled, the integrity of the data you send and receive cannot be guaranteed. An attacker could modify the data in transit, and you would have no way of knowing. This could range from subtle manipulations of the data you receive to the injection of malicious code or malware into your system. The consequences of such breaches of data integrity can be severe, depending on the nature of the data and the system.
The following code contains examples of disabled certificate validation.
Certificate validation is not enabled by default when _create_unverified_context is used. It is recommended to use
create_default_context instead. This method creates secure contexts that will verify certificates and check server hostnames (see
{rule:python:S5527} for more information) by default.
import ssl ctx1 = ssl._create_unverified_context() # Noncompliant ctx2 = ssl.create_default_context() ctx2.verify_mode = ssl.CERT_NONE # Noncompliant
import ssl # By default, certificate validation is enabled ctx1 = ssl.create_default_context() # The context can be specified for client or server use ctx2 = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.
To avoid running into problems with invalid certificates, consider the following sections.
If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.
In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.
The following code contains examples of disabled certificate validation.
Certificate validation is not enabled by default and has to be explicitly enabled through set_verify. By setting
SSL.VERIFY_NONE, no certificate validation will occur.
from OpenSSL import SSL
from OpenSSL.crypto import X509
ctx1 = SSL.Context(SSL.TLSv1_2_METHOD) # Noncompliant
ctx2 = SSL.Context(SSL.TLSv1_3_METHOD)
ctx2.set_verify(SSL.VERIFY_NONE, verify_callback) # Noncompliant
def bad_callback(
conn: SSL.Connection, cert: X509, errnum: int, depth: int, ok: int
) -> bool:
return True
ctx3 = SSL.Context(SSL.TLS_CLIENT_METHOD)
ctx3.set_verify(SSL.VERIFY_PEER, bad_callback) # Noncompliant
from OpenSSL import SSL ctx1 = SSL.Context(SSL.TLSv1_2_METHOD) ctx1.set_verify(SSL.VERIFY_PEER) ctx2 = SSL.Context(SSL.TLSv1_3_METHOD) ctx2.set_verify(SSL.VERIFY_PEER | SSL.VERIFY_FAIL_IF_NO_PEER_CERT) ctx3 = SSL.Context(SSL.TLS_CLIENT_METHOD) ctx3.set_verify(SSL.VERIFY_PEER | SSL.VERIFY_FAIL_IF_NO_PEER_CERT | SSL.VERIFY_CLIENT_ONCE, verify_callback)
By omitting the verify_callback argument, OpenSSL will use its built-in verification process. This can be trusted to be secure by
default (if the correct flags are set.)
Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.
To avoid running into problems with invalid certificates, consider the following sections.
If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.
In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.
The following code contains examples of disabled certificate validation.
The certificate validation gets disabled by setting verify to False. To enable validation set the value to
True or do not set verify at all to use the secure default value.
As part of its certification validation, Requests also verifies the server hostname with the certificate chain.
import requests
requests.request('GET', 'https://example.com', verify=False) # Noncompliant
import requests
# By default, certificate validation is enabled
requests.request('GET', 'https://example.com')
Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.
To avoid running into problems with invalid certificates, consider the following sections.
If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.
In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.
The following code contains examples of disabled certificate validation.
The certificate validation gets disabled by setting verify_ssl to False. To enable validation set the value to
True or do not set verify_ssl at all to use the secure default value.
As part of its certification validation, aiohttp also verifies the server hostname with the certificate chain.
import aiohttp
async def example():
async with aiohttp.ClientSession() as session:
session.get("https://example.com", verify_ssl=False) # Noncompliant
import aiohttp
# By default, certificate validation is enabled
async def example():
async with aiohttp.ClientSession() as session:
session.get("https://example.com")
Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.
To avoid running into problems with invalid certificates, consider the following sections.
If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.
In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.
The following code contains examples of disabled certificate validation.
The certificate validation gets disabled by setting verify to False. To enable validation set the value to
True or do not set verify at all to use the secure default value.
As part of its certification validation, HTTPX also verifies the server hostname with the certificate chain.
import httpx
httpx.get('https://example.com', verify=False) # Noncompliant
import httpx
# By default, certificate validation is enabled
httpx.get('https://example.com')
Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.
To avoid running into problems with invalid certificates, consider the following sections.
If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.
In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.