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: ...
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 headers that looks trivial until you ship it wrong. For Koa apps, the mechanics are easy: send Strict-Transport-Security over HTTPS. The hard part is rollout, preload, proxies, subdomains, and not bricking a staging or legacy setup by accident. This guide is the version I wish more teams had on hand: what to send, when to send it, and copy-paste Koa examples that won’t surprise you later. ...
HSTS is one of those headers that feels boring right up until it wrecks your local workflow. I’ve seen this happen in teams more than once: someone enables Strict-Transport-Security in a staging or shared dev environment, tests with a real-looking hostname, and suddenly half the team can’t load the app over HTTP anymore. Then people start clearing browser data, changing ports, restarting Docker, and blaming the reverse proxy. The real problem is usually simpler: the browser is doing exactly what HSTS told it to do. ...
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. ...
HSTS is one of those headers that’s boring right up until the day it saves you from a nasty downgrade or cookie theft issue. If you’re running a Crystal app with Kemal, HSTS is usually easy to add. The hard part is deciding how aggressive to be. Short max-age? Long max-age? Include subdomains? Preload? Those choices have real operational consequences, especially if you run staging environments, legacy subdomains, or mixed infrastructure. ...