API Shouldn't Redirect HTTP to HTTPS

Original Article ↗ Hacker News Discussion ↗

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.