Security-Headers

HSTS and mixed content get lumped together because they both live in the HTTPS world. But they solve different problems, fail in different ways, and trip up different teams. If you’re building or maintaining a site, you need to understand the gap between them: HSTS tells the browser to always use HTTPS for your domain. Mixed content happens when an HTTPS page still loads some resources over HTTP. That distinction matters. I’ve seen teams proudly enable HSTS and assume they’re done, while their pages still pull images, scripts, or CSS over plain HTTP. That’s not “mostly secure.” That’s a site with sharp edges. ...

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. ...

If you host on Azure Static Web Apps, HSTS looks deceptively simple. You want one header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Done, right? Not quite. Azure Static Web Apps is great for shipping frontend apps fast, but once you care about security headers, especially HSTS, you run into a design constraint: you do not get full control over the edge like you would with a custom reverse proxy, Nginx, or a tuned CDN setup. ...

A lot of backend teams assume HSTS is a “browser thing” that only matters for HTML pages. I’ve seen this mistake more than once on API-only services: the frontend is on HTTPS, the API is on HTTPS, everybody checks the box mentally, and nobody notices the API never sends Strict-Transport-Security. That gap usually survives until someone looks at headers closely, or until an auth callback, API docs page, or admin route gets hit over plain HTTP somewhere in the chain. ...

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. ...

HSTS on Deno Deploy is one of those security controls that’s easy to enable and surprisingly easy to get wrong. If you’re serving anything real on Deno Deploy, you should at least make an intentional decision about HTTP Strict Transport Security instead of leaving it as “probably fine.” HSTS tells browsers: only talk to this site over HTTPS for a set period of time. That shuts down a whole class of downgrade and SSL-stripping attacks. ...

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. ...

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. ...

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. ...

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. ...