If you run Envoy at the edge, HSTS is one of those headers you should set deliberately instead of “getting around to it later”. It is simple on paper: tell browsers to always use HTTPS for your site. In practice, the question is where to inject it in an Envoy-based stack, and that choice affects operability, consistency, and the blast radius of mistakes. For Envoy, there are a few common approaches: ...
HTTP Strict Transport Security looks simple: send one header, force HTTPS, move on. In practice, HSTS failures are boring, subtle, and easy to miss until production traffic hits an unexpected edge case. I’ve seen teams “enable HSTS” and still leave redirect loops, missing subdomains, CDN overrides, and preload-breaking configs in place. The header was technically there, but the deployment was not actually trustworthy. If you want to audit HSTS properly, compare multiple methods. No single check catches everything. ...
Moving a site from HTTP to HTTPS sounds easy until you do it on a real production system with old links, mixed content, proxies, CDNs, and a few mystery services nobody wants to touch. Then HSTS enters the picture and raises the stakes, because once browsers cache that policy, mistakes stop being easy to undo. That does not mean HSTS is risky in a bad way. I’d still recommend it for most public sites. But I would not enable it blindly on day one with a one-year max-age and preload unless I was very sure the whole stack was clean. ...
HSTS on Railway sounds simple: add a header, force HTTPS, done. In practice, the right place to set it depends on how you deploy, whether you use Railway’s edge, and how much control you actually have over redirects and custom domains. If you run production apps on Railway, HSTS is usually worth enabling. But it’s one of those headers that can absolutely hurt you if you switch it on carelessly, especially with preload or a long max-age before your subdomains are ready. ...
If you serve HTTPS and you’re not using HSTS, you still have a weak first step. That sounds harsh, but it’s true. A site can have a perfectly valid TLS setup and still be vulnerable to downgrade tricks that push users onto plain HTTP before HTTPS ever gets a chance. HSTS fixes that by telling browsers: “for this site, never use HTTP again.” That one rule shuts down a whole class of annoying and very real attacks. ...
HSTS on Heroku looks simple right up until you ship it wrong and lock users into a bad HTTPS setup. I’ve seen this happen a few times: someone enables SSL on Heroku, adds a redirect to HTTPS, throws in Strict-Transport-Security, and calls it done. Then a week later they realize staging is broken, a custom domain is misconfigured, or preload was enabled before every subdomain was actually ready. Heroku makes TLS termination easy. That does not mean HSTS is automatic, or safe by default. ...
A few years ago, I helped clean up a messy HTTPS rollout for a mid-sized SaaS app. On paper, the setup looked fine: valid TLS cert, HTTPS redirect, load balancer in front, and a decent-looking security checklist in the wiki. In production, it was shaky. Users could still hit http:// directly. Some static assets loaded from old subdomains with mismatched certificates. One internal team wanted to turn on HSTS preload immediately because they’d read that “preload means maximum security.” That would have been a great way to lock broken TLS behavior into every browser. ...
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. ...