HSTS

HTTP Strict Transport Security sounds simple: send one response header and browsers stop using plain HTTP for your domain. With AWS API Gateway, it’s a little messier. The short version: API Gateway can return Strict-Transport-Security, but whether HSTS actually helps depends on how clients reach your API, whether you use a custom domain, and whether any HTTP endpoint still exists in front of it. If you only remember one thing, remember this: HSTS protects browser traffic for hostnames, not APIs in the abstract. If your API is consumed by server-to-server clients, mobile apps, or SDKs, HSTS is mostly irrelevant. If your API is called from browser-based apps on a custom domain, then it absolutely matters. ...

HSTS report-only mode sounds like something browsers should support. They don’t. That’s the first thing worth clearing up, because a lot of developers go looking for a Strict-Transport-Security-Report-Only header and assume they just haven’t found the right syntax yet. There is no standardized HSTS report-only header implemented by browsers in the way Content-Security-Policy-Report-Only works. So if you’re trying to safely “test” HSTS before enforcing it, the real answer is a mix of: ...

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 in Ktor is simple once you know where to put it, and easy to get wrong if you treat it like just another header. Strict-Transport-Security tells browsers: “for this domain, use HTTPS only for a while.” After a browser sees it over a valid HTTPS response, future HTTP requests get upgraded to HTTPS before they ever leave the browser. That blocks protocol downgrade attacks and strips out a whole class of sloppy redirect problems. ...

HSTS on Railway sounds simple: add a header, force HTTPS, done. In practice, the right place to set it depends on how you deploy, whether you use Railway’s edge, and how much control you actually have over redirects and custom domains. If you run production apps on Railway, HSTS is usually worth enabling. But it’s one of those headers that can absolutely hurt you if you switch it on carelessly, especially with preload or a long max-age before your subdomains are ready. ...

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

If you host a static site or public assets on Google Cloud Storage, HSTS sounds simple: send Strict-Transport-Security and force browsers onto HTTPS. The catch: with GCS, whether you can actually do that depends entirely on how you serve content. That’s the whole game. Google Cloud Storage is great at object serving. It’s not great at acting like a full-featured web server with flexible response header control in every hosting mode. So if you want HSTS on a GCS-backed site, you need to pick the right architecture first. ...

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