HSTS is one of those controls people configure once, feel good about, and then forget for two years. That is exactly why it needs monitoring. I’ve seen teams proudly preload a domain, then quietly lose the header on a CDN edge, a redirect hop, or a newly launched subdomain. Nobody notices until someone runs a scan, a browser behavior changes, or a security review turns up a gap that has been sitting there for months. ...
If you run a Play app in production and you’re still treating HTTPS as “mostly enabled,” HSTS is one of the easiest ways to stop users from ever hitting your site over plain HTTP again. The idea is simple: tell the browser, “for this domain, only use HTTPS for a while.” After that, even if someone clicks an old http:// link or a network attacker tries SSL stripping, the browser upgrades the request before it leaves the machine. ...
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. ...
I’ve seen this pattern more than once: a team moves fast, sets up HTTPS, gets the padlock in the browser, and assumes transport security is done. Then somebody runs a header scan and finds the obvious gap: no HSTS. That was the situation with a small Bun-powered app I helped review. The site served authenticated pages over HTTPS, redirected HTTP to HTTPS, and generally looked fine at a glance. But the first request was still vulnerable. A user typing example.com or following an old http:// bookmark could be intercepted before the redirect ever helped. ...
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. ...
I’ve seen a lot of teams treat HSTS like a checkbox header: add one line, ship it, move on. That mindset is how you brick subdomains, lock users into bad TLS setups, or convince yourself you’re “secure” while your first request is still vulnerable. If you’re serving a Zig app with Zap, HSTS is simple to add, but the hard part is knowing when to add it, how aggressively to configure it, and how to roll it out without surprising production. ...
If you’re shipping a Vapor app over HTTPS and you haven’t enabled HSTS yet, you’re leaving a pretty dumb gap in your transport security. HSTS stands for HTTP Strict Transport Security. It tells browsers: “for this domain, stop trying plain HTTP and always use HTTPS.” That matters because a redirect from http:// to https:// is not enough. An attacker sitting on the network can tamper with that first insecure request before the browser ever gets redirected. ...
HTTP Strict Transport Security is one of those headers that looks trivial and still gets deployed wrong all the time. If you run a Nim app with Jester, HSTS is easy to add. The hard part is adding it in the right place, with the right conditions, and without bricking a staging domain or forcing bad HTTPS assumptions behind a reverse proxy. HSTS tells the browser: only use HTTPS for this site keep doing that for a specific amount of time optionally apply the rule to subdomains optionally treat the domain as preload-eligible The header looks like this: ...
HSTS on Vercel is one of those settings that looks trivial right up until you lock yourself out of a subdomain for a year. If you deploy on Vercel, you already get HTTPS by default. That solves transport encryption. HSTS solves a different problem: making browsers refuse plain HTTP for your domain after they’ve seen your policy once. That sounds great, and usually it is. But HSTS is also sticky, cached aggressively by browsers, and very easy to over-apply. I’ve seen teams flip on includeSubDomains without thinking through preview apps, legacy subdomains, or weird internal tools hanging off the same parent domain. ...
I’ve seen this bug ship more than once: a team enables HSTS, feels good about “forcing HTTPS,” and then learns the hard way that HSTS does nothing for a user’s very first HTTP visit. That gap matters. If you’re deciding between an HTTPS redirect and HSTS, the answer is not “pick one.” You need both. The real question is which one protects the user first, and how to roll them out without breaking login flows, subdomains, or that one forgotten asset host from 2018. ...