Http-Headers

HSTS looks simple: send one response header and browsers stop using HTTP for your site. In practice, teams still get it wrong all the time, especially in Erlang systems sitting behind load balancers, reverse proxies, or mixed legacy setups. I’ve seen Cowboy apps ship with “secure” configs that quietly do nothing, break subdomains, or lock a bad decision into browsers for months. If you’re running Cowboy, the tricky part usually isn’t the header syntax. It’s where you set it, when you set it, and whether your deployment actually matches what the browser thinks is happening. ...

A few years ago I helped clean up a small Rust service that had all the usual “we’ll fix it before launch” security leftovers. The app used Rocket. TLS was terminated at a reverse proxy. Redirects from HTTP to HTTPS were working. Cookies were marked Secure. Everyone on the team assumed transport security was done. It wasn’t. The missing piece was HSTS: Strict-Transport-Security. Without it, first requests were still vulnerable to downgrade tricks, bad links, stale bookmarks, and users typing example.com without the scheme. The site looked secure in normal testing, but the browser had no instruction to always use HTTPS on future visits. ...

If you run a Gin app over HTTPS and you’re not sending HSTS, you’re leaving an easy downgrade path open. HSTS tells browsers: “stop trying plain HTTP for this site; always use HTTPS.” That shuts down a bunch of avoidable mistakes and some very real attack paths. The catch: HSTS is one of those headers that looks trivial but can absolutely bite you in production if you roll it out carelessly. I’ve seen teams turn it on with preload flags before they were ready, then spend days untangling broken subdomains and internal tools. ...