Welcome to HSTS Guide

HSTS looks simple: send one response header and browsers stop using HTTP for your site. In practice, Starlette apps often get HSTS half-right, which is usually the worst version of security. The app sends the header sometimes, or only on a couple routes, or it trusts the wrong proxy headers, or someone enables preload without understanding the blast radius. Here are the mistakes I see most often with Starlette, and how I’d fix them. ...

HSTS in Rails is one of those security wins that looks trivial right up until you break a domain for months. If you run a Rails app over HTTPS, you should probably send Strict-Transport-Security. But the real question for a developer team isn’t “should we use HSTS?” It’s “which HSTS policy should we ship, and how safely can we get there?” Rails makes this pretty easy, but the tradeoffs matter. A weak HSTS policy leaves downgrade risk on the table. An aggressive one can lock users and subdomains into HTTPS before your infrastructure is ready. ...

I’ve seen this pattern a lot on managed platforms: the app is already on HTTPS, the TLS certificate is valid, redirects are enabled, and everyone assumes transport security is done. It usually isn’t. For one client project running on DigitalOcean App Platform, the site looked fine at a glance. https:// loaded cleanly, the platform handled certificates, and HTTP redirected to HTTPS. But the app still had a gap that matters in the real world: no HSTS header. ...

HTTP Strict Transport Security sounds simple: send one response header and browsers stop using HTTP for your site. That’s true, but HSTS is one of those headers that can quietly break things if you turn it on too aggressively. I’ve seen teams copy a preload-ready header from a blog post, deploy it, and then discover some forgotten subdomain is still serving plain HTTP. Now users can’t reach it at all. ...

HTTP Strict Transport Security looks simple: send a header, force HTTPS, move on. Until somebody sets it too aggressively. Then you get broken subdomains, painful rollback, local dev weirdness, certificate fires, and a support thread full of “the site is down for me” even though your origin is technically healthy. I like HSTS. You should probably use it. But I’ve also seen teams turn a good control into a self-inflicted outage because they treated it like a checkbox instead of a deployment with blast radius. ...

HTTP Strict Transport Security looks simple: send one header, browsers stop using HTTP, done. That’s the theory. In real Quarkus apps, HSTS usually goes wrong in boring, expensive ways: wrong environment, wrong proxy setup, bad preload assumptions, or turning it on before the whole domain is actually HTTPS-ready. If you’re building Java services with Quarkus, these are the mistakes I see most often and how to fix them without breaking production. ...

GraphQL APIs usually get plenty of attention around auth, query depth limits, and introspection. Transport security often gets treated like a box to check: “we already use HTTPS.” That’s not enough. If your Apollo Server is reachable over plain HTTP, or if browsers can be tricked into making the first request insecurely, HTTPS alone leaves a gap. HSTS closes that gap for browser clients by telling them: from now on, only use HTTPS for this host. ...

A lot of teams treat Server-Sent Events like “just another endpoint.” That’s how you end up with a perfectly secure app shell over HTTPS and a quietly fragile event stream still hanging onto old HTTP assumptions. I’ve seen this play out in production: the page loads fine, login works, API calls are on HTTPS, HSTS is enabled on the main site, and yet live updates randomly fail, especially after deploys, browser restarts, or when users hit older bookmarked URLs. The culprit was SSE over an incomplete HTTPS setup. ...

HTTP Strict Transport Security sounds boring right up until you need it. HSTS is the header that tells browsers: “stop trying plain HTTP for this site, always use HTTPS.” That shuts down protocol downgrade attacks and removes a whole class of accidental insecure requests. If your site is on Cloudflare Pages, adding HSTS is easy. Adding it safely is the part people mess up. I’ve seen teams copy-paste max-age=31536000; includeSubDomains; preload into production without checking whether every subdomain actually supports HTTPS. That’s how you brick old marketing hosts and weird internal tools. ...

HSTS is one of those headers that looks trivial until you ship it wrong. For Flask apps, the basic idea is simple: tell browsers to always use HTTPS for your domain. That blocks protocol downgrade attacks and kills off a whole class of “accidentally served over HTTP” mistakes. But HSTS also has sharp edges. If you enable it too early, on the wrong host, or behind a misconfigured proxy, you can lock users into a broken site. ...