Web-Security

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

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

HTTP Strict Transport Security sounds simple: send one response header and browsers stop using HTTP for your site. In practice, Java teams still get it wrong. I’ve seen Spring Boot apps enable HSTS in one environment, forget it behind a reverse proxy, then wonder why production behavior doesn’t match local testing. If you run a Spring Boot app over HTTPS, HSTS is usually the right move. The real question is how to enable it, how aggressive to be, and when not to turn on the stricter options. ...

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