HTTPS

GitHub Pages makes HTTPS easy. HSTS is where people usually get tripped up. The short version: if you use the default *.github.io domain, GitHub handles HTTPS and HSTS for you. If you use a custom domain, you need to understand what GitHub controls, what your DNS provider controls, and one annoying limitation: you generally can’t arbitrarily add or tune response headers on GitHub Pages itself. That limitation matters because HSTS is just an HTTP response header: ...

HSTS looks deceptively simple. One header, one line, done. That’s exactly why teams get it wrong. I’ve seen production rollouts where HSTS was added in a hurry, tested once in Chrome, and then forgotten until something broke: login subdomains stopped working, staging got pinned to HTTPS, or preload got enabled before the company actually controlled every edge of its domain. The header itself is easy. The operational blast radius is where people mess up. ...

Moving a site from HTTP to HTTPS sounds easy until you do it on a real production system with old links, mixed content, proxies, CDNs, and a few mystery services nobody wants to touch. Then HSTS enters the picture and raises the stakes, because once browsers cache that policy, mistakes stop being easy to undo. That does not mean HSTS is risky in a bad way. I’d still recommend it for most public sites. But I would not enable it blindly on day one with a one-year max-age and preload unless I was very sure the whole stack was clean. ...

HSTS on Fly.io looks simple right up until it breaks logins, bricks a staging subdomain, or quietly does nothing because the header never reaches the browser. I’ve seen all three. If you’re deploying on Fly.io, the platform handles TLS nicely, but HSTS is still your job. That’s where people get tripped up: they assume “HTTPS is on” means “HSTS is done.” Not even close. Here are the mistakes I see most often, why they happen on Fly.io, and how I’d fix them. ...

If your domain is on the HSTS preload list and you need it out, the process is simple on paper and annoyingly slow in practice. The hard part is not the form submission. The hard part is understanding what browsers will keep doing after you change your headers, and making sure you do not trap users behind a broken HTTPS setup while preload removal works its way through browser releases. ...

HSTS is one of those headers that’s easy to enable and surprisingly easy to get wrong. If you run a REST API with Express, HSTS tells clients: “Stop trying plain HTTP for this host. Use HTTPS only for a while.” That sounds simple, but the details matter a lot in production, especially behind proxies, load balancers, and CDNs. This guide is the version I wish more API teams used: what to send, when to send it, and what not to do. ...

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

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

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