HTTPS Redirects and HSTS: Roll Out a Durable Browser Policy

An HTTP-to-HTTPS redirect tells a client where to send a request. HTTP Strict Transport Security, or HSTS, tells a supporting browser to use HTTPS for a host for a stated period after learning the policy over a valid HTTPS connection. Because the browser remembers that instruction, an HSTS rollout deserves more planning than adding an ordinary response header during a deployment.

Make the HTTPS service complete first

Verify the certificate and routing for every hostname visitors use, including www and older names that redirect to the preferred host. Test deep links, forms, sign-in callbacks, static assets, and error pages. A redirect from an old HTTPS hostname still needs a valid certificate on that old hostname before the browser can safely receive the redirect.

Check the proxy-to-application scheme information too. If the application believes an HTTPS request arrived over HTTP, it may generate wrong links or a redirect loop. Repair the trusted proxy configuration before attributing the symptom to HSTS.

Choose the policy scope deliberately

The HSTS maximum age controls how long the browser retains the instruction. The includeSubDomains option extends its scope to subdomains, which can affect services owned by another team. Inventory those services and verify their HTTPS readiness before applying a parent-domain policy that covers them.

For an organization with a marketing site, a legacy customer portal, and several partner integrations, assign an owner to each hostname. One team's successful website launch does not demonstrate that the entire namespace is ready. A forgotten internal hostname can become an operational problem if users' browsers receive a broader policy.

Increase persistence through observed stages

Start with a deliberately limited policy lifetime that fits your rollout plan, test real journeys, and increase persistence after observing the result. Record the exact header served externally rather than only the value in a configuration file. Different proxy routes or error responses may set headers inconsistently, so sample more than the homepage.

Use a clean browser profile for a first-visit test and a profile that has already learned HSTS for a repeat-visit test. Those clients can behave differently by design. If a browser upgrades a URL without contacting the HTTP endpoint, its stored policy may explain why the server's redirect logs show no request.

Treat preload as a separate commitment

Browser preload participation has its own requirements and removal process. Evaluate it only after confirming the long-term HTTPS commitment and control of affected names. Do not add preload-related directives by copying a generic security-header bundle. Document the policy owner and the recovery implications so a future migration preserves the required certificates and routing rather than assuming that serving HTTP temporarily will be harmless.

Certificate monitoring becomes part of this commitment. A remembered HTTPS policy cannot repair an expired certificate or an unavailable secure listener. Ensure alerts reach an operator through a working channel and test the renewal path before extending the browser policy's lifetime.

Mozilla's HSTS reference explains browser behavior. See our HTTPS-proxied MicroBin guide for deployment context, and consult LayerOne documentation before changing the server configuration.