Security-Headers

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

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