Aws

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

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

I’ve seen this mistake a lot: a team puts a static site in S3, flips on static website hosting, maps a DNS record, and calls it done. The site is fast, cheap, and easy to deploy. It also can’t do HSTS correctly. That matters because once you care about HTTPS, you usually want to enforce it hard. HSTS tells browsers: “Stop trying HTTP for this site. Only use HTTPS for a while.” Without it, users can still hit the site over plain HTTP first, get redirected, and stay exposed to downgrade and interception risks on that first request. ...