Website Security

HSTS Explained: Enforce HTTPS Without Locking Out Your Domain

HSTS tells browsers to use HTTPS for future visits. Learn max-age, subdomains, preload risk and a staged deployment plan.

Muhammad Azhar August 14, 2026 Reviewed August 21, 2026 3 min read

HSTS instructs a browser that a domain should use HTTPS for a defined period. After receiving the header over a valid HTTPS connection, the browser upgrades later HTTP requests before sending them.

Deploy in stages

  1. Fix HTTPS and redirect HTTP.
  2. Start with a short max-age.
  3. Monitor every required host.
  4. Increase duration gradually.
  5. Add includeSubDomains only when all subdomains support HTTPS.

Preload is a commitment

Browser preload lists can enforce HTTPS before the first visit. Removal takes time, so do not preload a domain with forgotten or externally managed subdomains.

What HSTS does not do

It does not fix expired certificates or application vulnerabilities. A certificate warning remains a stop condition.

HSTS begins after a trusted visit

Unless the domain is preloaded, the browser must first receive the header over valid HTTPS. Keep the HTTP-to-HTTPS redirect because new clients and non-browser tools may not have stored policy.

Recovery planning

Automate certificate renewal and alert well before expiry. With a long max-age, a certificate outage cannot be worked around by temporarily serving HTTP, which is precisely the protection and the operational responsibility.

Choose max-age through staged confidence

Begin with a short policy after HTTPS works across the site, then increase it while monitoring certificate renewal and subdomains. Add includeSubDomains only when every current and future subdomain can support HTTPS. Preload is a separate, difficult-to-reverse commitment and should not be treated as a badge.

Operational readiness is part of the security control

Automate renewal, monitor from outside the hosting provider and keep account ownership current. Test the certificate served by the CDN or load balancer, not merely the file installed on the origin. Maintain redirects for new clients and tools that have not stored HSTS state.

HSTS prevents a browser from accepting an HTTP downgrade; it does not fix mixed content, vulnerable application code or an invalid certificate. Treat those as separate deployment checks.

Prove HTTPS coverage before enforcing HSTS

HSTS tells a browser to replace future HTTP requests with HTTPS for a defined period. That prevents downgrade opportunities after the browser has learned the rule, but a bad deployment can also make a hostname unreachable until its certificate or HTTPS configuration is repaired.

Inventory production hostnames, redirects, certificates and third-party services. Start with a short max-age on the main host. Increase it only after renewal and rollback procedures have been tested. Add includeSubDomains when every current and delegated subdomain supports HTTPS.

Treat preload as a lasting commitment

Browser preload lists close the first-visit gap, but removal is slow and does not instantly update every installed browser. Do not submit a domain merely to improve a scanner score. Confirm long-term ownership of all covered names and the ability to renew certificates reliably.

Monitor the header on successful pages, redirects and edge responses. Alert on certificate expiry and DNS changes. HSTS is a transport rule, not proof that the application, cookies or content are secure.

Stage changes on a hostname that follows the same certificate and redirect process. A development site with different infrastructure cannot expose renewal or subdomain failures that affect production.

Sources and further reading