API Shouldn't Redirect HTTP to HTTPS

Original Article ↗ Hacker News Discussion ↗

APIs that automatically redirect plaintext HTTP requests to HTTPS can silently leak API keys and other credentials to anyone able to sniff or intercept that first unencrypted hop. Commenters argue that, unlike human-facing websites where redirects and HSTS make sense, machine clients should fail fast: either refuse HTTP entirely (e.g., close port 80 or return a clear 4xx error) and possibly revoke keys seen over HTTP, and HTTP clients and SDKs should avoid following redirects by default. The broader exchange revisits when, if ever, plain HTTP is acceptable, weighing ease of deployment and legacy or local use cases against pervasive risks of man-in-the-middle attacks and content injection.

HSTS, redirects, and client behavior

  • Several comments stress that HSTS is fundamentally designed for stateful, user-facing browsers, not transient API clients; most non-browser HTTP libraries don’t honor HSTS or preload lists.
  • There’s debate whether generic client APIs like fetch should implement HSTS or refuse http: by default; many prefer a hard error for HTTP unless explicitly overridden.
  • cURL’s default of not following redirects automatically is praised as a deliberate and safer design.

How APIs should handle HTTP

  • Strong consensus that APIs should not silently redirect HTTP→HTTPS, because secrets may already have been sent in cleartext before the redirect.
  • Suggested server-side behaviors:
    • Best: don’t listen on port 80 at all for the API, so no unencrypted path exists.
    • Next best: accept HTTP but immediately return a clear 4xx error explaining HTTPS is required.
    • Aggressive option: revoke any API key observed over HTTP, forcing rotation; seen as “correct but harsh” and potentially painful in real deployments.
  • Example: one major API provider updated behavior to return a structured 403 error for HTTP instead of redirecting.

HTTP vs HTTPS in general

  • Many argue that post-Snowden, all web traffic (including non-sensitive content) should be over HTTPS: prevents sniffing, ad/script injection, and large-scale passive surveillance.
  • Others defend HTTP in limited scenarios: retro/low-power devices, private networks, local services, educational use, or read-only/verifiable content; they emphasize simplicity, durability, and reduced dependence on certificate authorities.
  • There’s tension between “HTTPS everywhere” as a practical rule of thumb and concerns about dogma, complexity, and centralized CA power.

Security models: MITM and sniffing

  • Long subthread on terminology: some distinguish “passive sniffing” (e.g., on open Wi‑Fi) from active MITM; others treat any eavesdropping on the path as MITM.
  • Regardless of naming, commenters agree: HTTP lets anyone on the path read and potentially modify traffic; HTTPS only leaves endpoints, DNS, and SNI visible.

Status codes and protocol details

  • Debate over the “right” code for HTTP API access: 400 (bad request), 403 (forbidden), 404 (resource doesn’t exist on HTTP), or 426 (upgrade required).
  • 426 is attractive in theory but often misused in practice and has strict RFC requirements (Upgrade header, same connection).
  • Some note operational constraints: shared load balancers, ACME http‑01 validation, and mixed web/API hosting can make disabling port 80 non-trivial.