How to Roll Out HSTS Safely: max-age, includeSubDomains, Preload, and Rollback Planning
https://vulnify.app/blog/hsts-rollout-max-age-includesubdomains-preload

Learn how to roll out HSTS safely using staged max-age values, includeSubDomains planning, preload requirements, certificate checks, and a practical rollback strategy.

HTTP Strict Transport Security, or HSTS, tells supporting browsers to use HTTPS for a site and to refuse insecure HTTP connections for the duration of the policy. It is a powerful transport-hardening control, but it is also persistent by design. A rushed HSTS rollout can lock users out of legacy subdomains, internal tools, or services that are not ready for HTTPS. The safest approach is gradual. Confirm that HTTPS works everywhere it needs to work, start with a short max-age , observe production behavior, increase the duration, then consider includeSubDomains and preload only when the entire domain namespace is ready. This guide explains that progression and how to verify the policy users actually receive. What HSTS actually does A typical HSTS header looks like this: Strict-Transport-Security: max-age=31536000; includeSubDomains When a browser receives the header over a valid HTTPS connection, it remembers that the host should be contacted only over HTTPS until the max-age expires. If a user later types an HTTP URL, the browser upgrades the request before sending it over the network. HSTS does not replace a valid TLS certificate. If the certificate is invalid, the browser can refuse the connection and the user cannot simply click through the warning in the normal way for an HSTS host. That is part of the protection, but it means certificate management must be reliable before the policy becomes long-lived. Understand the first-visit limitation HSTS is learned over HTTPS. A browser that has never seen the policy does not know the host is HSTS-protected yet. Redirecting HTTP to HTTPS remains important because first-time visitors may begin on an HTTP URL. Preloading can address part of this first-visit gap for domains included in browser preload lists, but preload introduces stronger operational commitments. Choose max-age deliberately max-age is specified in seconds. It tells the browser how long to remember the HTTPS-only policy. Starting immediately with a year-long value is unnecessary risk if you have not verified every important route and dependency. Initial observation: Strict-Transport-Security: max-age=300 After validation: Strict-Transport-Security: max-age=86400 Mature policy: Strict-Transport-Security: max-age=31536000 These values are examples of a staged process, not a mandatory schedule. The key principle is to increase persistence only after the site has behaved correctly under the shorter policy. Be cautious with includeSubDomains includeSubDomains extends the policy to subdomains. That can be desirable because it prevents an overlooked subdomain from remaining available over HTTP. It can also break legacy services that do not support HTTPS correctly. Before enabling it, inventory active subdomains and important delegated services. Check marketing tools, old APIs, support portals, static asset hosts, mail-related web interfaces, vendor-managed subdomains, and temporary migration hosts. If even one required subdomain cannot operate over HTTPS, a parent-domain HSTS policy with includeSubDomains may cause disruption. Treat HSTS preload as a separate decision HSTS preload places a domain into a browser-maintained list so HTTPS-only behavior can apply before the browser has visited the site. This is stronger than simply sending an HSTS header. Preload eligibility has requirements, including a long max-age , includeSubDomains , and the preload token, and the domain must satisfy the current preload service criteria. Do not add preload merely because a scanner says the token is missing. Preload is an operational commitment affecting the domain and subdomains. Removal is possible but not instantaneous across every browser release, so plan as if rollback will take time. Hypothetical scenario: a forgotten legacy subdomain A company serves its main website entirely over HTTPS and enables: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload The main site works perfectly. Two days later, finance staff report that reports.example.com no longer loads. The hostname points to an old vendor appliance that only supports HTTP and was never included in the web team's inventory. The browser now insists on HTTPS because the parent policy covers subdomains. Removing the header from the main site does not immediately erase the policy already cached by users. The incident could have been avoided by inventorying subdomains, testing HTTPS readiness, and staging the policy before adopting includeSubDomains and preload. Fix redirects before relying on HSTS HTTP requests should have a clear path to the canonical HTTPS destination for clients that have not learned HSTS. Avoid redirect chains such as HTTP to HTTPS on one hostname, then to another hostname, then back to a final path. Each extra hop creates complexity and can hide downgrade or canonicalization mistakes. Use the Redirect Chain Checker to review the full public path. HSTS and redirects solve related but different problems: redirects handle requests that arrive on the wrong URL, while HSTS changes browser behavior for future requests. Make certificate automation boring first A long-lived HSTS policy makes certificate failures more visible because users cannot simply continue past an invalid certificate. Before increasing max-age , make sure certificate issuance, renewal, hostname coverage, and deployment are reliable. Use the SSL Checker to review public certificate validity, expiry, chain trust, protocol support, and related TLS signals. Test alternate hostnames and critical subdomains, not only the apex domain. Clean up mixed content too HSTS does not automatically make every embedded HTTP asset safe. Pages may still contain legacy HTTP references, and browsers handle active and passive mixed content differently. Use the Mixed Content Checker to identify insecure asset references after an HTTPS migration or template change. A practical HSTS rollout plan 1. Inventory hostnames and dependencies List active public subdomains, vendor-managed hosts, old applications, static asset domains, and any service that shares the parent domain. Confirm which ones must remain reachable. 2. Verify HTTPS everywhere that matters Check certificate validity, hostname coverage, redirects, mixed content, and application behavior. Fix certificate or redirect problems before HSTS makes them persistent for browsers. 3. Start with a short max-age Deploy HSTS on the main hostname with a short duration. Monitor support issues, browser behavior, and critical workflows. Use the HSTS Checker to confirm the public header. 4. Increase the duration gradually Once the HTTPS configuration is stable, increase the duration in controlled steps. Document the policy owner and expected final value so the header does not remain in an accidental trial state forever. 5. Add includeSubDomains only after inventory Retest all required subdomains first. Remember that subdomains managed by other teams or vendors are still affected by a parent-domain policy. 6. Consider preload last Review the current requirements at the preload service, confirm organizational ownership of the domain namespace, and make sure long-term HTTPS is a deliberate commitment. Plan rollback before you need it For a non-preloaded policy, setting max-age=0 instructs browsers that receive the new HTTPS response to remove the HSTS policy for that host. That does not instantly reach browsers that cannot connect to receive the new header, and it does not erase preload status. Keep certificate renewal and emergency DNS procedures documented. If a TLS outage occurs on an HSTS host, restoring valid HTTPS is usually a better recovery path than trying to weaken the transport policy under pressure. Common HSTS mistakes Enabling a long max-age before validating HTTPS. Adding includeSubDomains without a subdomain inventory. Adding preload because it appears in a generic hardening checklist. Assuming HSTS replaces HTTP-to-HTTPS redirects. Testing only the homepage and not alternate routes or hostnames. Ignoring certificate-renewal reliability. Forgetting legacy or vendor-managed subdomains. Treating a missing preload token as a vulnerability by itself. How Vulnify fits into HSTS validation The HSTS Checker provides a focused public check of header presence, max-age , includeSubDomains , and preload-related posture. Pair it with the SSL Checker , Redirect Chain Checker , and Mixed Content Checker when validating a broader HTTPS rollout. These checks show the public result. Your organization still needs the internal hostname inventory, ownership model, certificate automation, and rollback plan that determine whether a stricter HSTS policy is operationally safe. HSTS rollout checklist Inventory active hostnames and subdomains. Confirm valid HTTPS on required services. Review HTTP-to-HTTPS redirect chains. Remove mixed-content references. Start with a short max-age . Increase duration only after stable observation. Validate subdomains before includeSubDomains . Review current preload requirements before submission. Document certificate and rollback procedures. Retest the final public header. A staged HSTS rollout example A cautious rollout can begin with a short max-age on the primary HTTPS hostname after redirect and certificate behavior are confirmed. Monitor for subdomain problems, mixed content, certificate errors, and legacy HTTP-only services. If the environment remains stable, increase the duration in stages rather than jumping immediately to a one-year policy with subdomain coverage. Stage 1: max-age=300 Stage 2: max-age=86400 Stage 3: max-age=604800 Stage 4: max-age=31536000 Only then consider includeSubDomains and preload The exact stages can differ, but the principle is consistent: make reversibility easier while you learn how the real production estate behaves. Once long-lived HSTS is cached by browsers, correcting an accidental policy is much slower than changing a normal response header. Conclusion HSTS is most effective when it follows a reliable HTTPS deployment rather than trying to compensate for an unreliable one. Start small, validate the public result, make certificate renewal dependable, inventory subdomains, and treat preload as a deliberate long-term decision. A staged rollout provides the security benefit without turning a forgotten legacy hostname into an avoidable outage.