Browser reaches HTTPS
The site returns a Strict-Transport-Security header over a secure connection.
HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS for future connections to a host, even when someone enters an HTTP URL or follows an HTTP link.
The header is simple. The consequences of includeSubDomains and especially preload are not. Those choices deserve more thought than copying a hardening snippet and moving on.
HSTS is learned from an HTTPS response. Once the browser accepts the policy, future HTTP attempts to that host are upgraded to HTTPS before the request is sent. HSTS also makes certificate errors non-bypassable for that host.
The site returns a Strict-Transport-Security header over a secure connection.
The host is stored as HSTS for the duration defined by max-age.
The browser upgrades future requests before connecting over plaintext HTTP.
This is a common HSTS configuration. Each part changes either how long the policy lasts, how far it reaches, or how early the browser can know about it.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadmax-age=63072000Remember for about two years that this host must use HTTPS.includeSubDomainsApply the parent domain's HSTS policy to its subdomains too.preloadDeclare intent to join browser HSTS preload lists. This directive alone does not add the domain to those lists.max-age
The value is measured in seconds. Every valid HTTPS response carrying the header refreshes the expiration time.
max-age=315360001 yearmax-age=630720002 yearsincludeSubDomains
The parent policy also covers subdomains. That is useful only when those names can reliably support HTTPS.
Think beyond www. Legacy, vendor-managed, forgotten, nested, and internal names can matter too.
preload
Preloading can close HSTS's first-visit gap by placing qualifying domains into lists shipped with browsers.
It is an operational commitment, not a generic “make HSTS stronger” switch.
preload Actually MeansNormal HSTS begins after a browser securely visits the site and receives the header. Preloading changes that by allowing supported browsers to ship with the domain already treated as HTTPS-only.
That closes the first-visit gap, but it also creates a broader commitment: the base domain and covered subdomains need to remain HTTPS-capable.
preload is not the same as being preloaded.The directive signals intent. The domain still has to meet the preload requirements, be submitted, and then make its way into browser lists.
Submission requirements cover subdomains too. That includes internal names, so the decision needs to account for the whole namespace.
Removal can be requested, but the change has to propagate through browser release cycles. That can take months, which is why preload should be a deliberate decision rather than a default hardening step.
preload into production just because it appears in a hardening example. Inventory the domain namespace, confirm HTTPS support where required, understand the submission process, and opt in deliberately.The browser connects over HTTP, receives a redirect, and then requests the HTTPS URL.
Useful for:Getting ordinary HTTP visitors to the secure site.Once the policy is known, the browser upgrades the URL locally before making the network request.
Useful for:Removing the plaintext redirect step on later visits and enforcing HTTPS more strictly.The browser can know the domain is HTTPS-only before ever receiving an HSTS header from the site.
Useful for:Closing the first-visit gap when the operational commitment is justified.If someone requests an HTTP URL before the browser knows the site uses HSTS, that first connection can still happen over HTTP. A network attacker may try to interfere before the browser reaches HTTPS.
http://example.comHTTP connectionRedirecthttps://example.comhttp://example.comBrowser upgrades locallyhttps://example.comhttp://example.comPolicy already built into browser datahttps://example.commax-ageA tiny duration may technically enable HSTS while providing little lasting protection. Short values can make sense during rollout, but should match the deployment stage.
includeSubDomains can break names that cannot support HTTPS. Leaving it off can also leave related hosts outside the parent policy. Context matters.
preload was copied, not plannedThe token may appear even when the domain was never submitted. A domain that is actually preloaded carries obligations that outlive a simple header change.
A redirect happens after an HTTP request. HSTS, once known, can prevent that plaintext request from being sent at all.
Browsers do not offer the normal bypass path for invalid certificates on HSTS hosts. That is a security benefit and a reason to keep certificate management healthy.
max-age=0 means disableReceiving max-age=0 over HTTPS removes the host's stored HSTS policy. It does not remove a preload-list entry already shipped in browsers.
A strong-looking HSTS header does not tell you whether certificates are managed well, TLS configuration is current, mixed content exists, every subdomain is healthy, or the application itself is secure.
Confirm the header is returned where expected and evaluate the value the browser actually receives.
max-age in contextA short duration can be appropriate during rollout. A mature deployment usually calls for a deliberate, longer-lived policy.
Before praising or recommending includeSubDomains or preload, understand what else exists beneath the domain.
Preloading is optional and has operational consequences. Its absence does not, by itself, make HSTS ineffective.
Use our Security Header Checker to review the observed Strict-Transport-Security value alongside other common browser security headers.
Headers are one part of the browser security model. Penetration testing looks at how controls, application behavior, authorization, configuration, and attack paths work together in the real environment.