Verification must be on by default. If you offer a way to turn it off, make it explicit, noisy and awkward to leave on in production, and prefer safer alternatives such as a custom CA bundle or a pinned certificate. Most developers who disable checks only need to trust one internal certificate.
What switching it off does
The Python requests documentation says that when verify is set to false, requests will accept any TLS certificate presented by the server, ignore hostname mismatches and expired certificates, and make the application vulnerable to man-in-the-middle attacks. It says the option may be useful during local development or testing, and that by default verify is true. MITRE catalogues the broader weakness as CWE-295, improper certificate validation.
A flag named verify or insecure sitting in your SDK's options is a known source of trouble. It gets copied from a forum answer to silence an error, passes review because it "works", and ships.
Why developers reach for it
| Real need | Safer answer |
|---|---|
| Internal CA signs the server certificate | Let the user pass a CA bundle path |
| Self signed cert in a test environment | Trust that single certificate explicitly |
| Corporate proxy that re-signs traffic | Support the standard CA bundle environment variable |
| Hostname mismatch in a lab | Fix the certificate, or allow a named host override |
| Expired certificate | Renew it; there is no safe workaround |
The requests documentation shows the same idea: a list of trusted CAs can be provided through a path or the REQUESTS_CA_BUNDLE environment variable. If your SDK supports those, most people never need an off switch.
Steps to design the option
- Keep verification on, and make hostname checking part of it, with no separate way to disable only one.
- Offer a CA bundle option and honour the platform's standard environment variable for it.
- If you must offer a full disable, name it so the risk is obvious, for example one containing the words insecure and skip verify, not a bare boolean.
- Require it to be set in code or config, not through a casually inherited environment variable that could leak from a developer laptop into production.
- Print a warning every time the SDK starts with verification disabled, and again at a fixed interval in long running processes.
- Refuse to disable verification when the target is your production hostname, or when an environment marker says production, if that fits your product.
- Do the same checks for every transport your SDK supports, including any websocket or streaming client, since these often use separate code paths.
- Add tests: a bad certificate must fail by default, a good one must pass, and the disabled mode must log its warning.
What to put in the docs
Say plainly that disabling verification removes protection against interception, and show the CA bundle method first. Customers' security reviewers will look for this section, and a clear answer saves back and forth.
Also note the history: if an earlier version allowed an off switch by default or used an unsafe fallback, list the change in the changelog as a security note, following the pattern in how to write a security entry.
Quick check
Is it fine to disable verification in tests?
It is common, but prefer a test CA. If you do disable it, scope it to the test code and make sure it cannot reach production configuration.
Does a custom CA bundle weaken security?
It narrows or changes who you trust. Trust only the CA you intend to, and keep the bundle under change control.
Safeguard's policies and gates can flag risky settings in pull requests, and dependency scanning shows which TLS libraries are in your tree. The free scan is a quick start.
Sources
- Requests documentation: Advanced usage, SSL certificate verification
- CWE-295: Improper Certificate Validation
Last reviewed: 19 October 2026.
