Encryption in transit using TLS 1.2 or higher
Why it matters
Transmitting authentication tokens, session cookies, and personal data over cleartext HTTP exposes every byte to network-level interception — on public Wi-Fi, by ISPs, or via any on-path attacker. CWE-319 (Cleartext Transmission of Sensitive Information) and OWASP A02 (Cryptographic Failures) both flag this. NIST 800-53 SC-8 requires transmission confidentiality and integrity. Disabling certificate validation (rejectUnauthorized: false) is equally dangerous — it defeats TLS entirely, making the connection vulnerable to any man-in-the-middle. Modern hosting platforms (Vercel, Netlify) enforce TLS at the edge, but custom or self-hosted setups must be explicitly configured.
Severity rationale
High because a failing check means credentials, session cookies, and personal data are transmitted in cleartext — directly exploitable by any on-path observer, aligned with CWE-319 and OWASP A02 severity.
Remediation
For self-hosted deployments, enforce TLS 1.2+ in nginx:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
Never disable certificate validation in application code — remove any instance of rejectUnauthorized: false:
// Remove this from production code:
// https.request(url, { rejectUnauthorized: false }, callback)
// Default validates certificates:
https.request(url, callback)
Vercel and Netlify handle TLS automatically. For custom deployments, verify your HSTS header is set: Strict-Transport-Security: max-age=31536000; includeSubDomains.
Detection
-
ID:
tls-in-transit -
Severity:
high -
What to look for: List all external service connections (database, cache, API, message queue). For each connection, check server and hosting configuration for TLS version support. Look for
vercel.json,netlify.toml, server TLS settings, or load balancer configuration. Verify that no endpoints are served over plaintext HTTP for authenticated users. Check whether API calls to external services use HTTPS. Look for anyrejectUnauthorized: falsein outbound request code. -
Pass criteria: All authenticated and sensitive traffic is served over TLS 1.2 or higher. HTTP requests are redirected to HTTPS. Outbound API calls use HTTPS. No
rejectUnauthorized: falsein production code — minimum TLS 1.2 on 100% of external connections. Report: "X external connections found, all Y use TLS 1.2+." -
Fail criteria: The application accepts plaintext HTTP for authenticated endpoints. Sensitive data (credentials, tokens) transmitted over cleartext connections. Outbound HTTPS connections have certificate validation disabled.
-
Skip (N/A) when: Never — TLS is required for all production web applications.
-
Detail on fail:
"TLS version not verified — hosting provider configuration not found"or"rejectUnauthorized: false found in lib/external-api.ts — TLS certificate validation disabled for outbound requests" -
Remediation: For Vercel and Netlify deployments, TLS 1.2+ is enforced by the platform. For self-hosted apps:
# nginx: enforce TLS 1.2+ ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on;// Never disable certificate validation in production: // Bad: https.request(url, { rejectUnauthorized: false }, callback) // Good (default behavior validates certificates): https.request(url, callback)
External references
- cwe · CWE-319 — Cleartext Transmission of Sensitive Information
- owasp:2021 · A02 — Cryptographic Failures
- nist:rev5 · SC-8 — Transmission Confidentiality and Integrity
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-hardening·automated
- 2026-04-18·v1.1.0·Severity raised low → high; failing check means cleartext credentials, not "hosting platform already handles it". Rationale rewritten to describe failure-state impact.·by spot-check-adjudication