Rule Information
Tags
gosecuritytlshttpcleartextman-in-the-middleCWE-319OWASP-A02
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset golang/GO-NET-001 --project .1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
`http.ListenAndServe()` starts an HTTP server without TLS encryption. All transmitted data — login credentials, session cookies, API keys, personal information, financial data, and application payloads — travels in plaintext over the network and can be read or modified by any network observer on the path between client and server.
**Threat model**: - "**Same network (Wi-Fi, corporate LAN)**: Any device on the same network can passively" capture all HTTP traffic using standard tools (Wireshark, tcpdump). Coffee shop Wi-Fi, shared office networks, and corporate LANs are all attacked this way. - "**Network infrastructure**: ISPs, VPN providers, and enterprise proxies can inspect" and modify HTTP traffic in transit. - "**MITM attacks**: ARP poisoning, rogue Wi-Fi access points, and BGP hijacking can" redirect HTTP traffic through attacker-controlled infrastructure.
**Cookie theft**: Session cookies transmitted over HTTP can be stolen and used to hijack authenticated sessions without knowing the user's password. The `Secure` cookie flag instructs browsers to only send cookies over HTTPS — but the flag is meaningless if the server itself doesn't use HTTPS.
**HTTP Strict Transport Security (HSTS)**: Requires TLS to be configured first. HSTS tells browsers to always use HTTPS for a domain for a specified duration. `http.ListenAndServe()` cannot benefit from HSTS.
**When HTTP (non-TLS) is acceptable**: - Internal health check endpoints binding to `localhost` or `127.0.0.1` only. - When TLS is terminated at a load balancer or reverse proxy (nginx, Caddy, AWS ALB) and the connection from LB to server is on a trusted private network or localhost. - Development servers that never handle real user data.
**Modern alternatives for TLS in Go**: - `http.ListenAndServeTLS(addr, certFile, keyFile, handler)` — standard TLS - `golang.org/x/crypto/acme/autocert` — automatic Let's Encrypt certificate management - Caddy web server with reverse proxy — automatic HTTPS with zero configuration - **crypto/tls** with `tls.NewListener` for fine-grained TLS control
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Session Hijacking
Session cookies transmitted over HTTP are visible to any network observer. An attacker who intercepts the `Set-Cookie: session_id=abc123` header can replay that cookie to impersonate the user for the lifetime of the session.
2
Credential Interception
Login forms that POST over HTTP send username and password in plaintext. The HTTP POST body is fully readable in tcpdump/Wireshark captures without any decryption.
3
Traffic Modification (Active MITM)
An active MITM attacker can inject JavaScript into HTTP responses to install persistent XSS payloads, steal future requests, or redirect users to phishing sites.
4
Downgrade Attacks
Without HSTS, browsers may follow links to the HTTP version of a site even if HTTPS exists. Attackers on the network can respond to HTTP requests before the HTTPS redirect reaches the user (SSL stripping attack).
How to Fix
Recommended remediation steps
- 1Use http.ListenAndServeTLS() with a valid certificate for all externally accessible servers.
- 2For automatic certificate management, use golang.org/x/crypto/acme/autocert (Let's Encrypt).
- 3Set TLSConfig.MinVersion to tls.VersionTLS12 or tls.VersionTLS13.
- 4Add HTTP Strict Transport Security (HSTS) header with a long max-age.
- 5Set secure cookie flags: `Secure: true, HttpOnly: true, SameSite: http.SameSiteLaxMode`.
- 6http.ListenAndServe is acceptable only on loopback (127.0.0.1) for internal health checks.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Detects all calls to net/http.ListenAndServe() regardless of address or handler. Flags any use — whether the address is 0.0.0.0, specific IP, or empty string. Localhost binding (127.0.0.1) is a known acceptable use case that produces a low-priority finding.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A02:2021 — Cryptographic Failures (cleartext transmission sub-category)
PCI DSS v4.0
Requirement 4.2.1 — Strong cryptography required for transmission of cardholder data.
Requirement 4.2.1.1 — All data transmission uses trusted keys/certificates.
NIST SP 800-53 Rev 5
SC-8 — Transmission Confidentiality and Integrity
HIPAA Security Rule
§164.312(e)(1) — Transmission security; encryption of ePHI in transit
CWE Top 25 (2024)
CWE-319 — Cleartext Transmission of Sensitive Information
References
External resources and documentation
CWE-319: Cleartext Transmission of Sensitive Information — MITREGo net/http ListenAndServeTLS documentationGo golang.org/x/crypto/acme/autocert (Let's Encrypt)OWASP Transport Layer Security Cheat SheetOWASP TLS Cipher String Cheat SheetHSTS — HTTP Strict Transport Security (MDN)Let's Encrypt — Free TLS Certificates
Similar Rules
Explore related security rules for Go
Frequently Asked Questions
Common questions about HTTP Server Without TLS
`http.ListenAndServe()` starts an HTTP server without TLS encryption. All transmitted
data — login credentials, session cookies, API keys, personal information, financial
data, and application payloads — travels in plaintext over the network and can be read
or modified by any network observer on the path between client and server.
**Threat model**:
- "**Same network (Wi-Fi, corporate LAN)**: Any device on the same network can passively"
capture all HTTP traffic using standard tools (Wireshark, tcpdump). Coffee shop Wi-Fi,
shared office networks, and corporate LANs are all attacked this way.
- "**Network infrastructure**: ISPs, VPN providers, and enterprise proxies can inspect"
and modify HTTP traffic in transit.
- "**MITM attacks**: ARP poisoning, rogue Wi-Fi access points, and BGP hijacking can"
redirect HTTP traffic through attacker-controlled infrastructure.
**Cookie theft**: Session cookies transmitted over HTTP can be stolen and used to
hijack authenticated sessions without knowing the user's password. The `Secure`
cookie flag instructs browsers to only send cookies over HTTPS — but the flag is
meaningless if the server itself doesn't use HTTPS.
**HTTP Strict Transport Security (HSTS)**: Requires TLS to be configured first.
HSTS tells browsers to always use HTTPS for a domain for a specified duration.
`http.ListenAndServe()` cannot benefit from HSTS.
**When HTTP (non-TLS) is acceptable**:
- Internal health check endpoints binding to `localhost` or `127.0.0.1` only.
- When TLS is terminated at a load balancer or reverse proxy (nginx, Caddy, AWS ALB)
and the connection from LB to server is on a trusted private network or localhost.
- Development servers that never handle real user data.
**Modern alternatives for TLS in Go**:
- `http.ListenAndServeTLS(addr, certFile, keyFile, handler)` — standard TLS
- `golang.org/x/crypto/acme/autocert` — automatic Let's Encrypt certificate management
- Caddy web server with reverse proxy — automatic HTTPS with zero configuration
- **crypto/tls** with `tls.NewListener` for fine-grained TLS control
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-NET-001 --project .
This vulnerability is rated as HIGH severity.
Yes! Code Pathfinder allows you to customize rules. Modify detection patterns, adjust severity levels, add custom sanitizers, and configure the rule to fit your organization's security policies.
New feature
Get these findings posted directly on your GitHub pull requests
The HTTP Server Without TLS rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.