TrustManager accepts all certificates
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A checkServerTrusted or checkClientTrusted implementation has no throw statement in its body, so it never rejects a certificate chain. This is the classic "trust all certificates" pattern used to silence TLS errors, and it removes certificate validation entirely, enabling man-in-the-middle attacks. Heuristic: a 10-line window is used to find the method body, so an unusually long legitimate validation method could be misread.
Why it matters
A checkServerTrusted or checkClientTrusted implementation that never throws accepts every certificate presented to it, valid or not, expired or not, self-signed or not. This is usually added to silence a TLS handshake error during development, but it removes certificate validation completely wherever it ships, which is a direct path to a man-in-the-middle attack.
How to fix it
Delegate to the platform's default trust manager (built from the default TrustManagerFactory) instead of writing a custom one, unless you have a specific, narrow reason to pin a certificate. If you do need custom logic, it must throw CertificateException for anything it does not explicitly accept.
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