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 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. ...
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. ...
HSTS and service workers overlap in ways that bite teams during deployment, local testing, and incident response. The short version: HSTS tells the browser to always use HTTPS for a host. Service workers only work in secure contexts, with a few localhost exceptions. If you get your HTTPS and redirect behavior wrong, service worker registration gets flaky fast. If you get HSTS wrong, rollback gets painful because browsers cache the policy. I’ve seen teams debug “random” service worker failures that were really bad TLS, mixed hostnames, or a stale HSTS policy. This guide is the practical version. ...
If you run GraphQL Yoga in production without HSTS, you’re trusting every first insecure hop a browser might take before it reaches your HTTPS endpoint. That’s a bad bet. HSTS, or HTTP Strict Transport Security, tells browsers: “stop trying plain HTTP for this site; use HTTPS only.” For a GraphQL API, that matters more than people think. GraphQL often carries auth tokens, session cookies, admin operations, and introspection data you really don’t want exposed over downgraded or intercepted connections. ...
If you’ve ever copied this header without thinking too hard about it, you’re not alone: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload It shows up in blog posts, server templates, security scanners, and “best practices” snippets. Then six months later someone realizes staging is broken, a subdomain can’t be reached, or the preload submission was a terrible idea. The biggest source of confusion is max-age. People treat it like a vague “security on/off” switch. It’s not. It’s a cache lifetime, and getting it wrong can lock users into behavior you didn’t mean to enforce. ...
HTTP Strict Transport Security, or HSTS, is one of those security headers that feels deceptively simple. Set one response header, ship it, done. Except that’s not really how it works in production. If you run a Django app and want HSTS configured properly, you need to understand what it actually does, how Django exposes it, and how to roll it out without accidentally breaking local development, subdomains, or a half-migrated environment. ...
HSTS looks simple: send one header and the browser forces HTTPS from then on. In Laravel, that usually means one middleware or one web server config change. And yet, teams still manage to break logins, lock users into bad cert setups, or preload domains before they’re actually ready. I’ve seen all three. If you run a Laravel app, HSTS is worth doing. You just need to avoid the usual footguns. ...