Posts

If you’re serving a Fiber app over HTTPS and you haven’t set HSTS yet, you’re leaving a pretty obvious gap in transport security. HSTS tells the browser: “stop trying plain HTTP for this site, always use HTTPS.” That blocks protocol downgrade attacks, strips out a whole class of SSL-stripping nonsense, and reduces accidental insecure requests from users who type example.com instead of https://example.com. For Go developers, the good news is that HSTS is just a response header. The bad news is that it’s also one of those headers that can lock users into a bad config if you ship it carelessly. ...

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

If you use WebSockets in a browser app, HSTS absolutely matters. A lot of teams set Strict-Transport-Security for normal page loads and APIs, then forget that their frontend also opens ws:// or wss:// connections. That gap creates weird mixed transport behavior at best and a downgrade risk at worst. The short version: modern browsers generally apply HSTS to WebSocket connections too. If a host is known to be HSTS, a ws:// URL to that host is treated like wss:// before the network request goes out. That’s good news, but there are edge cases and deployment mistakes that still break things. ...

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

HSTS in FastAPI is one of those things that looks trivial until you ship it wrong. The header itself is simple: Strict-Transport-Security: max-age=31536000; includeSubDomains But the decision around where to set it, when to enable it, and whether to preload it can absolutely break local development, staging subdomains, and legacy services you forgot still exist. If you run FastAPI in production, you want HSTS. The real question is which implementation path fits your stack. ...

HSTS looks simple: send Strict-Transport-Security, force browsers onto HTTPS, move on. Then AWS gets involved. I’ve seen teams enable HTTPS on an ALB or CloudFront, add a redirect somewhere, and assume they’re done. They aren’t. HSTS in AWS usually breaks because the setup spans multiple layers: browser, CloudFront, load balancer, origin, app, and sometimes a second redirect hiding in the middle. Here are the mistakes I see most often, and how to fix them. ...

A few years ago I watched a team turn on HSTS in production with a one-line config change and a lot of confidence. By lunch, support had a queue full of users who couldn’t reach a legacy upload app on a forgotten subdomain. By the end of the day, the team had learned the hard way that HSTS is easy to enable and surprisingly hard to roll back once browsers cache it. ...

I’ve seen the same Render setup more than once: HTTPS is enabled, the app works, redirects are in place, and everyone assumes transport security is “done.” Then someone runs a header scan and realizes the site still skips one of the most useful protections you can ship in five minutes: HSTS. This is a real-world style case study based on a common Render deployment pattern. Same stack, same hosting model, same mistake. ...