API Gateway

HTTP Strict Transport Security sounds simple: send one response header, force browsers onto HTTPS, done. In practice, the hard part is deciding where to manage it in Kong and how aggressively to roll it out without breaking edge cases. If you run Kong API Gateway, you usually have a few choices: Set HSTS in Kong itself Set HSTS in an upstream app behind Kong Set HSTS at an outer load balancer or CDN instead of Kong Use a phased rollout with short max-age first, then increase later I’m opinionated on this one: if Kong is your main HTTPS entry point, HSTS usually belongs there. It keeps policy consistent across services and avoids every team reinventing the same header logic. But there are trade-offs, and some teams absolutely should not flip on preload-style settings on day one. ...

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