Will It Vibe?http.ListenAndServe with no TLS anywhere in the project
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
http.ListenAndServe serves plain HTTP, and no file in the scanned project calls ListenAndServeTLS, imports crypto/tls, or uses autocert, so traffic is likely served unencrypted. Heuristic: it cannot see an external reverse proxy that terminates TLS in front of this process.
Why it matters
Plain HTTP sends every request and response, including cookies, auth headers, and request bodies, in clear text. Anyone positioned on the network path (a shared Wi-Fi network, a compromised router, a misconfigured proxy) can read or modify that traffic. Finding no TLS setup anywhere in the project strongly suggests the service is either meant to sit behind a TLS-terminating proxy that was not documented here, or is genuinely serving plaintext in production.
How to fix it
If this service is directly internet-facing, switch to ListenAndServeTLS with a real certificate, or use golang.org/x/crypto/acme/autocert to provision one automatically. If it always runs behind a reverse proxy or load balancer that terminates TLS (nginx, Caddy, a cloud load balancer), that is a legitimate setup, but confirm it is actually true for every environment this binary runs in, including local and staging, and document it so the next reader is not left guessing.
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