Disable "InsecureRequestWarning: Unverified HTTPS request" warning in Python Requests
If you've worked with Python's requests library to make HTTPS calls, you've almost certainly run into this wall of yellow text in your console:
InsecureRequestWarning: Unverified HTTPS request is being made.
Adding certificate verification is strongly advised.
See: https://urllib3.readthedocs.io/en/latest/advanced-layout.html#ssl-warnings
This warning is common, frequently Googled, and often "fixed" in a way that can introduce serious security risks. It typically appears when you make a request while bypassing SSL/TLS certificate validation, usually by setting verify=False in your requests call.
import requests
# This line will trigger the warning
response = requests.get('https://some-self-signed-site.com', verify=False)
Your first instinct might be to find the quickest way to silence this warning. But before you copy-paste that one-liner, let's understand why it's there, when it's okay to disable, and how to fix the underlying problem correctly.
What this warning actually means?
That InsecureRequestWarning isn't just Python being annoying. It's a critical security alert.
When you set verify=False, you are telling requests (and its underlying library, urllib3) to not verify the identity of the server you're talking to. In a normal, secure HTTPS connection, your client does the following:
1. Receives the server's SSL certificate.
2. Checks if the certificate was issued by a trusted Certificate Authority (CA).
3. Verifies that the certificate's domain name matches the server you're trying to reach.
By setting verify=False, you skip all of this. You are essentially telling your program: "Connect to this server, even if you can't prove it is who it claims to be."
This opens the door for a Man-in-the-Middle (MITM) attack. An attacker could intercept your traffic, present a fake certificate, and your program would happily connect, sending all your sensitive data (like API keys, passwords, or user data) directly to the attacker.
When is it (relatively) safe to disable?
Disabling this warning (and using verify=False) is never recommended for production code that interacts with public or third-party APIs.
However, there are a few specific, controlled scenarios where it might be a necessary, temporary evil:
- Local Development: You're testing against a local server (https://localhost:8000) that's using a temporary, self-signed certificate.
- Internal Networks: You're on a corporate or private network, connecting to an internal tool that uses a self-signed certificate issued by your own company (and which your machine doesn't trust by default).
- Legacy Systems: You're interacting with an old, internal hardware device (like a printer or router) that has a web interface with an expired or invalid certificate.
In these cases, you have assessed the risk and decided that the connection is trustworthy, even if the certificate isn't. Now, you just want to clean up your console logs.
The quick fix: how to disable the warning
If you've evaluated the risk and are sure you want to proceed, here is the standard way to disable only the InsecureRequestWarning.
Place this code near the top of your application's entry point:
import requests
import urllib3
# This is the line that does the magic
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
# Now, this call will no longer produce a warning
response = requests.get('https://some-self-signed-site.com', verify=False)
By importing urllib3 and calling disable_warnings(), you are silencing all warnings of that specific class. This is much better than disabling all Python warnings, as it's targeted and won't hide other potential problems.
The better fix: solving the root problem
Disabling warnings is like taking a painkiller for a broken leg. It stops the noise, but it doesn't fix the underlying break. Here are the correct ways to solve this.
Method 1: The obvious fix (don't use verify=False)
The simplest solution? Just remove verify=False from your call. The requests library is smart and will use your system's trusted certificate store by default. This is the correct approach for 99% of public APIs.
Method 2: the enterprise fix (trust your company's certificate)
If you are connecting to an internal site that uses a self-signed certificate, don't disable verification. Instead, get a copy of your company's CA certificate (usually a .pem or .crt file) and tell requests to trust it.
You can pass the path to this certificate file directly to the verify parameter:
# Provide the path to your company's trusted CA bundle
cert_file = '/path/to/my-corporate-ca.pem'
response = requests.get('https://internal.company.com', verify=cert_file)
This is the best and most secure solution for internal applications. You are not disabling security; you are simply extending the circle of trust to include your own organization's certificates.
Method 3: the modern fix (use certifi)
Sometimes, the built-in certificate store on your (or your server's) operating system is old or incomplete. The certifi package provides an up-to-date, curated bundle of root certificates.
You can install it (pip install certifi) and then tell requests to use its bundle:
import requests
import certifi
# This tells requests to use certifi's bundle instead of the system's
response = requests.get('https://some-public-api.com', verify=certifi.where())
Conclusion: be careful, not just quiet
That InsecureRequestWarning is your friend. It's a reminder to think about security before you ship your code.
While urllib3.disable_warnings() is a handy tool for cleaning up logs in controlled development environments, always stop and ask why the warning is appearing. More often than not, the right solution is to fix the certificate verification, not to hide the warning about it.
