HTTP Client `danger_accept_invalid_certs` Permitted MITM Credential

Affected Versions

The Vulnerability Explained

A critical security flaw in the HTTP client configuration allowed any caller to disable TLS certificate validation entirely. The build_http_client function accepted a validate_certs boolean parameter that, when set to false, would invoke danger_accept_invalid_certs(true) on the underlying reqwest::ClientBuilder:

if !validate_certs {
    builder = builder.danger_accept_invalid_certs(true);
}

This is precisely the wrong way to handle certificate problems in production code. The danger_accept_invalid_certs method in reqwest is explicitly documented as dangerous—it disables all certificate validation, including hostname verification and trust chain checking. When combined with Basic Auth credentials, this creates a perfect storm: authentication secrets travel over connections that could be intercepted by any attacker positioned between the client and server.

The attack scenario is straightforward. A developer or automated system sets validate_certs to false to work around a certificate issue—perhaps a self-signed certificate in a staging environment, or an expired certificate on a legacy server. An attacker on the same network segment (public WiFi, compromised router, malicious hotspot, or ARP-spoofed LAN) presents a fake certificate for the target hostname. Without validation, the client accepts this certificate and establishes a TLS connection to the attacker. The attacker decrypts the traffic, extracts the Basic Auth credentials, then forwards the request to the real server—completely invisible to both parties.

The reqwest documentation warns that this setting "is highly discouraged and should only be used for debugging purposes." Yet the API made it available as a simple boolean toggle, with no audit trail, no warning, and no alternative path for legitimate certificate customization.

The Fix

The fix removes the dangerous escape hatch entirely. Instead of silently disabling security, the code now returns an error with clear guidance:

if !validate_certs {
    return Err(
        "Disabling TLS certificate validation is not permitted because it exposes credentials to man-in-the-middle attacks. Use a custom CA certificate instead.".to_string(),
    );
}

This change preserves all legitimate use cases through the existing use_custom_ca_certificate path, which properly validates certificates against a custom trust anchor rather than accepting any certificate whatsoever. The error message explicitly names the security risk and points developers toward the correct solution.

The before/after comparison reveals the shift in security posture:

Key Takeaways

• Never expose danger_accept_invalid_certs through a boolean parameter—the convenience of a quick toggle becomes the path of least resistance, and developers will use it in production without understanding the consequences.

• Certificate problems have certificate solutions—self-signed certificates belong in a custom CA store, not in a bypassed validation path. The custom_ca_certificate_path option provides the flexibility without the exposure.

• Error messages are security controls—the new error doesn't just stop dangerous behavior; it educates the developer about why the behavior is dangerous and what to do instead.

• API design is threat modeling—the original design assumed that callers would responsibly use validate_certs. The fix assumes that dangerous capabilities will be misused, and removes them.

How Orbis AppSec Detected This

Source: The validate_certs parameter passed to build_http_client

Sink: reqwest::ClientBuilder.danger_accept_invalid_certs(true) invoked when certificate validation is disabled

Missing control: No restriction on when TLS validation could be disabled; no requirement for custom CA certificates as an alternative

CWE: unknown

Fix: Replace the dangerous TLS bypass with a hard error that directs developers toward proper certificate management

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

The validate_certs parameter was a foot-gun: an easy-to-use option that destroyed the security guarantees of TLS. The fix recognizes that developers facing certificate errors need guidance toward proper solutions, not an escape hatch that exposes credentials. By converting the silent vulnerability into an explicit error with actionable advice, the code now protects users while still supporting legitimate certificate customization through the custom_ca_certificate_path mechanism.