Posts

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

HSTS in Apache is one of those things that’s surprisingly easy to turn on, but also easy to get wrong if you rush it. If you’re serving a site over HTTPS, you should almost certainly be sending the Strict-Transport-Security header. It tells browsers: “from now on, only ever talk to me over HTTPS.” That closes off a whole class of downgrade and SSL-stripping attacks, and it helps make your HTTPS setup actually stick. ...

If you’re using Cloudflare in front of your site, turning on HSTS is one of those small changes that can meaningfully tighten security with almost no ongoing maintenance. But it’s also one of those settings that’s easy to misunderstand, and if you flip it on carelessly, you can absolutely lock yourself into HTTPS behavior before your site is fully ready. So let’s do this the practical way: what HSTS actually does, what Cloudflare changes, the safe rollout path, and exactly where to click. ...

HSTS in Nginx is one of those changes that looks tiny in config, but it has very real consequences. Done right, it closes off downgrade attacks and makes sure browsers stop trying plain HTTP for your domain. Done wrong, you can lock users into a broken HTTPS setup for weeks or months. I’ve seen teams treat HSTS like a checkbox: add one header, deploy, move on. That’s how people end up with subdomains they forgot about, stale certificates, and support tickets from users who can’t get in anymore. The header is simple. The rollout is the hard part. ...

If you run a Gin app over HTTPS and you’re not sending HSTS, you’re leaving an easy downgrade path open. HSTS tells browsers: “stop trying plain HTTP for this site; always use HTTPS.” That shuts down a bunch of avoidable mistakes and some very real attack paths. The catch: HSTS is one of those headers that looks trivial but can absolutely bite you in production if you roll it out carelessly. I’ve seen teams turn it on with preload flags before they were ready, then spend days untangling broken subdomains and internal tools. ...

HSTS preloading is one of those rare web security features that’s both boring and incredibly useful. If you run a real production site, especially one that handles logins, payments, admin panels, or anything remotely sensitive, getting onto the HSTS preload list is usually worth doing. Why? Because normal HSTS only starts protecting users after they’ve visited your site once over HTTPS and received the Strict-Transport-Security header. Preloading removes that first-visit gap. Browsers ship with your domain baked into a hardcoded HTTPS-only list, so they’ll never attempt plain HTTP in the first place. ...

If your site still leaves any room for browsers to touch plain HTTP, you have a weak spot. That’s exactly the problem HSTS solves. HSTS stands for HTTP Strict Transport Security. It’s a response header that tells browsers: “From now on, only talk to me over HTTPS. Don’t even try HTTP.” Once a browser sees that policy, it stops making insecure requests to your site for a defined period. That sounds small, but it closes one of the oldest and most annoying gaps in web security: the first insecure request. ...