Almost never. Disabling certificate verification makes a client accept any server, including an attacker in the middle. If a sample hits a certificate error, fix the trust setup instead, for example by pointing the client at a custom certificate authority bundle for the test server.
Why this shortcut spreads
A tutorial author runs a sample against a local server with a self-signed certificate. The client raises an error. The quickest fix is a flag that turns checking off. The sample works, gets published, and thousands of readers learn that certificate errors are something you switch off.
The Requests documentation describes the intended behaviour: it verifies SSL certificates for HTTPS requests like a web browser, and verification is enabled by default. It raises an SSLError when it cannot verify. That error is the library doing its job.
The Python ssl documentation makes the stakes concrete. For the mode CERT_NONE, it says that with client side sockets just about any certificate is accepted, and that validation errors, such as an untrusted or expired certificate, are ignored. It also notes that PROTOCOL_TLS_CLIENT uses CERT_REQUIRED and enables check_hostname by default. Defaults are safe; samples that change them are the risk.
What an unverified connection loses
| Check | What it prevents | Lost when verification is off |
|---|---|---|
| Chain of trust | Connecting to a server a trusted authority never vouched for | Yes |
| Expiry | Using stale certificates | Yes |
| Hostname match | Talking to the wrong server | Yes, if hostname checking is also off |
Without these checks, encryption still happens, but you may be encrypting a conversation with an attacker.
Better ways to get a sample working
- For a local or test server, create a certificate authority or a self-signed certificate and point the client at it explicitly. Many HTTP clients accept a path to a certificate bundle.
- Use a certificate from a public authority for hosted demo services, so readers need no special setup.
- If a sample truly needs to skip verification for a local only demonstration, put it behind a clearly named flag that is off by default and explain the risk in a warning box.
- Never place the disable option in the main code path of a tutorial.
- Test the sample against a server with a wrong certificate and confirm it fails.
import requests
# Trust a specific test certificate authority, keep verification on.
response = requests.get(
"https://test.example.com/health",
verify="/path/to/test-ca.pem",
timeout=10,
)
print(response.status_code)
What reviewers should look for
When reviewing docs or sample pull requests, search the diff for flags that disable verification, suppress warnings about insecure requests, or set the verify mode to none. Each deserves a comment. A suppressed warning is a sign someone saw the problem and chose to hide it.
Add the same search to your docs build. It takes minutes and catches the pattern before it is published. Related reading: should you disable FastAPI docs in production covers another default worth reviewing.
Safeguard's code scanning and policy gates can flag insecure client settings in repositories, and dependency scanning checks the libraries samples use. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is verify False acceptable for a quick local test?
It works, but it normalises a risky habit. Prefer trusting your test certificate authority, and keep any bypass behind an explicit off by default flag.
Does turning off verification stop encryption?
No. Traffic is still encrypted, but the client no longer confirms who is on the other end.
Sources
Last reviewed: 19 October 2026.
