Will It Vibe?HttpClientHandler TLS certificate validation disabled
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
ServerCertificateCustomValidationCallback on an HttpClientHandler/WebRequestHandler/SocketsHttpHandler unconditionally returns true, so that HttpClient accepts any certificate for any host, including an attacker-in-the-middle presenting a self-signed one.
Why it matters
ServerCertificateCustomValidationCallback set to unconditionally return true tells HttpClient to accept any TLS certificate for any host on that handler, including an expired, self-signed, or attacker-controlled certificate. Traffic sent through that HttpClient is then vulnerable to interception, and this is often added to silence a certificate error in one environment without realizing it removes protection everywhere that handler is used.
How to fix it
Remove the callback so the default certificate chain and hostname validation applies. If the client legitimately needs to trust a specific certificate that is not in the system trust store (an internal CA or a pinned certificate), validate the certificate's thumbprint or chain against a known-good value inside the callback instead of returning true unconditionally, so only that specific certificate is trusted.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo