HTTP Strict Transport Security (HSTS)
Explain how browsers learn HTTPS-only policy, why redirects differ, and how subdomain coverage and preload choices affect deployment and recovery.
What it means
HSTS tells supporting browsers to use HTTPS for a host after receiving the policy over a secure connection. It reduces opportunities to downgrade later requests to HTTP. Subdomain coverage and preload decisions have operational consequences when some services do not support HTTPS.
A practical example
A company first confirms HTTPS works on its main site, then checks every relevant subdomain before extending the policy. It treats preload as a separate deployment decision and plans certificate monitoring to avoid preventable outages.
What to check
Verify reliable TLS, choose an appropriate policy duration, assess subdomain readiness, and understand how browsers learn the policy. Test redirect behavior alongside the actual response header.
A common pitfall
An ordinary HTTP-to-HTTPS redirect can still expose the first insecure request. HSTS learned from a secure response improves later behavior; preload changes that initial-request situation.
Think it through
Can a team safely include all subdomains without checking legacy hosts?
Answer: It should verify that those hosts support HTTPS first, because browsers will enforce the policy on covered names.
Follow the browser's first visit
Imagine a fictional learner types the academy's hostname without a scheme. If the browser starts with HTTP and only then receives a redirect, the first exchange has different protection from a request that was upgraded before being sent.
An HSTS policy learned over HTTPS affects later requests within its validity and scope. Preloading changes how participating browsers know about policy before an ordinary first visit. These are related but distinct mechanisms, so document which behavior the deployment actually relies on.
Subdomains create shared obligations
Suppose the main portal supports HTTPS reliably but an old workshop subdomain does not. Extending the policy to subdomains can break access to that legacy service. The policy owner needs an inventory and migration plan before making the broader commitment.
Certificate renewal, DNS changes, and service ownership become important operational dependencies. A long-lived browser policy cannot always be undone instantly just by removing the response header from today's server configuration.
Test delivery at the real edge
The header a developer configures may differ from the response delivered through a CDN or reverse proxy. Inspect the final HTTPS response and the intended redirect behavior. Check relevant hosts and response paths rather than relying on a single screenshot of a configuration file.
For the academy, stage policy changes with a duration appropriate to the rollout and verify service readiness. A more aggressive value is not automatically a better decision when recovery and subdomain ownership are unclear.
For a paper exercise, compare three learners: one with no learned policy, one with an unexpired learned policy, and one whose browser includes a preload entry. Trace how each attempts an insecure URL. Then add a legacy subdomain and explain the operational consequence of including it. The goal is understanding browser behavior over time, including the obligations created by the policy.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: HTTP Strict Transport Security