If you run APIs over HTTPS, HSTS looks like an easy win. Set one header, tell clients to never use HTTP again, and reduce downgrade and cookie leakage risks. That’s the sales pitch. For browser-facing traffic, I’m generally a fan. For API endpoints, the answer is more nuanced. HSTS absolutely helps in some API deployments, does almost nothing in others, and can create operational headaches if you roll it out carelessly. ...

I’ve seen this mistake a lot: a team puts a static site in S3, flips on static website hosting, maps a DNS record, and calls it done. The site is fast, cheap, and easy to deploy. It also can’t do HSTS correctly. That matters because once you care about HTTPS, you usually want to enforce it hard. HSTS tells browsers: “Stop trying HTTP for this site. Only use HTTPS for a while.” Without it, users can still hit the site over plain HTTP first, get redirected, and stay exposed to downgrade and interception risks on that first request. ...

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

HSTS is one of those headers that’s dead simple on paper and weirdly easy to mess up in production. If you run a TypeScript app with tRPC, you usually don’t “add HSTS to tRPC” directly. You add it at the HTTP layer that serves your tRPC endpoint: Express, Fastify, Next.js custom server, Nginx, your edge platform, or your CDN. That distinction matters because if you set it in the wrong place, your API might still be exposed over plain HTTP during redirects or on subdomains you forgot existed. ...

HTTP Strict Transport Security is one of those headers you set once, then forget about until you realize your rollout plan was sloppy. If you run a Dart app with Shelf, HSTS is straightforward: send a Strict-Transport-Security response header on HTTPS responses, and don’t break local development while doing it. This guide is the practical version: what to send, when to send it, and copy-paste Shelf middleware you can actually use. ...

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 looks simple: send one response header and browsers stop talking to your site over plain HTTP. The catch is that HSTS is one of those headers that can absolutely improve security and absolutely break things if you roll it out carelessly. I’ve seen teams flip on includeSubDomains in production and then spend the afternoon finding forgotten subdomains, old staging boxes, and random vendor callbacks still using HTTP. If you’re running Fastify, you’ve got a few ways to handle HSTS: ...