Security Headers8 min read

HSTS Explained

Understand HTTP Strict Transport Security (HSTS), the Strict-Transport-Security header, preload lists and HTTPS best practices.

Published: 2026-08-07

HTTP Strict Transport Security (HSTS) is a web security mechanism that instructs browsers to communicate with a website exclusively over HTTPS. Once a browser receives a valid HSTS policy, it automatically upgrades future HTTP requests to HTTPS, helping protect users from protocol downgrade attacks and certain types of man-in-the-middle (MITM) attacks.

HSTS is implemented using the Strict-Transport-Security HTTP response header and is widely recommended for websites that fully support HTTPS. It strengthens transport security by ensuring that browsers avoid insecure HTTP connections whenever possible.

What Is HSTS?

HSTS is a browser security feature that tells clients to access a website only through encrypted HTTPS connections for a specified period of time. After receiving the policy, compliant browsers automatically rewrite future HTTP requests to HTTPS before sending them over the network.

Why HSTS Is Important

Without HSTS, users may accidentally access a website using HTTP, allowing attackers on the network to intercept or modify traffic before the browser is redirected to HTTPS. HSTS removes this opportunity after the browser has learned the site's policy.

Enforces HTTPS connections.
Reduces downgrade attacks.
Helps prevent SSL stripping.
Improves transport security.
Protects authenticated sessions on trusted devices.

How HSTS Works

When a user first visits a website over HTTPS, the server includes the Strict-Transport-Security response header. The browser stores the policy locally and automatically upgrades all future requests to HTTPS until the policy expires.

User Visits HTTPS Website
↓
Server Sends HSTS Header
↓
Browser Stores Policy
↓
Future HTTP Requests
↓
Automatically Upgraded to HTTPS

The Strict-Transport-Security Header

The Strict-Transport-Security header contains directives that define how long the browser should enforce HTTPS and whether the policy applies to subdomains.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Common HSTS Directives

Directive	Purpose
max-age	Defines how long the policy remains active
includeSubDomains	Applies the policy to all subdomains
preload	Requests inclusion in browser preload lists

What Is SSL Stripping?

SSL stripping is a downgrade attack in which an attacker attempts to keep a victim connected over HTTP instead of HTTPS. HSTS helps prevent this attack after the browser has learned or preloaded the website's HSTS policy.

Browser Support

All major modern browsers support HSTS and automatically enforce stored policies. Once a browser records an HSTS policy, users cannot bypass certificate warnings until the policy expires or is removed.

💡 Enable HSTS only after confirming that your entire website and all required subdomains are fully accessible over HTTPS.

⚠️ If HTTPS is misconfigured after HSTS is enabled, users may be unable to access the website until the configuration is fixed or the stored policy expires.

Understanding max-age

The max-age directive specifies how long, in seconds, the browser should remember the HSTS policy. Every time the browser receives a new Strict-Transport-Security header, the timer is refreshed using the latest value provided by the server.

max-age Value	Approximate Duration
300	5 minutes
86400	1 day
2592000	30 days
31536000	1 year

includeSubDomains

The includeSubDomains directive extends the HSTS policy to every subdomain of the current domain. This helps ensure that all parts of a website consistently use HTTPS, but it should be enabled only after verifying that every subdomain fully supports secure connections.

The HSTS Preload List

Some browsers include a built-in HSTS preload list containing domains that should always be accessed over HTTPS. Websites added to this list are protected from the very first visit because the browser already knows to use HTTPS before making any network request.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Requirements for Preloading

To qualify for browser preload lists, websites must satisfy several technical requirements that ensure HTTPS is consistently available across the entire domain.

Serve valid HTTPS on the main domain.
Support HTTPS on all subdomains.
Use a sufficiently long max-age value.
Enable includeSubDomains.
Include the preload directive.

Advantages of HSTS

Benefit	Description
Automatic HTTPS	Browsers upgrade insecure requests
Downgrade Protection	Helps prevent SSL stripping attacks
Improved Security	Reduces accidental HTTP usage
Simplified User Experience	No manual HTTPS typing required

Potential Challenges

Because browsers strictly enforce HSTS policies, configuration mistakes can temporarily make a website inaccessible. Careful testing should always be completed before deploying long-lived HSTS policies, especially when using includeSubDomains or preload.

Issue	Possible Impact
Expired TLS certificate	Browser blocks access
HTTPS unavailable	Users cannot connect
Broken subdomain	May become inaccessible with includeSubDomains

When to Use HSTS

HSTS is recommended for websites that are permanently served over HTTPS. Organizations should ensure that HTTPS is correctly configured across their infrastructure before enabling long-term HSTS policies or requesting preload status.

💡 Begin with a relatively short max-age value during initial deployment. After confirming that HTTPS works reliably for all users and services, gradually increase the duration to a longer production value.

⚠️ Do not enable includeSubDomains unless every existing and future subdomain is guaranteed to support HTTPS. Otherwise, legitimate services may become unreachable in users' browsers.

Common Mistakes

HSTS is highly effective when deployed correctly, but configuration mistakes can have long-lasting consequences because browsers cache HSTS policies locally. Careful planning and testing are essential before enabling long-term policies or joining the preload list.

Enabling HSTS before HTTPS is fully configured.
Using includeSubDomains while some subdomains still support only HTTP.
Applying an excessively long max-age during initial deployment.
Adding the preload directive before meeting preload requirements.
Allowing TLS certificates to expire after enabling HSTS.
Assuming HSTS replaces other HTTPS security best practices.

Best Practices

Serve every page exclusively over HTTPS.
Deploy HSTS only after verifying HTTPS across the entire website.
Start with a shorter max-age and increase it after successful testing.
Enable includeSubDomains only when every subdomain supports HTTPS.
Monitor TLS certificates and renew them before expiration.
Use HSTS together with modern TLS versions and strong cipher suites.

💡 Treat HSTS as the final step in an HTTPS deployment. Once users' browsers cache the policy, temporary HTTPS configuration problems may immediately become visible because browsers will refuse insecure fallbacks.

⚠️ Submitting a domain to the browser HSTS preload list is a long-term commitment. Removing a domain from preload lists can take significant time because browser updates are released on their own schedules.

Frequently Asked Questions

Does HSTS replace HTTPS?

No. HSTS depends on HTTPS. It instructs browsers to always use HTTPS after learning the policy, but it does not provide encryption by itself.

Does HSTS protect the first visit?

Not always. On the very first visit, a browser has not yet learned the HSTS policy. Websites included in browser HSTS preload lists are protected from the first visit because browsers already know to use HTTPS.

What happens if a TLS certificate expires?

If HSTS is active and the website presents an invalid or expired certificate, browsers typically block access without allowing users to bypass the warning, helping prevent man-in-the-middle attacks.

Should every website use HSTS?

Websites that are permanently available over HTTPS should generally enable HSTS. Sites that still require HTTP or have subdomains without HTTPS should resolve those issues before deployment.

What does the preload directive do?

The preload directive indicates that a website would like to be included in browser HSTS preload lists. The domain must still satisfy preload requirements before browser vendors include it.

Helpful Security Header Tools

An HSTS Header Generator creates correctly formatted Strict-Transport-Security headers, a Security Headers Generator helps configure multiple recommended HTTP security headers, an HTTP Header Generator builds custom response headers for testing, a TLS Version Checker verifies which TLS protocol versions a server supports, and a Certificate Expiration Checker helps monitor TLS certificate validity to avoid service interruptions after HSTS is enabled.

Conclusion

HTTP Strict Transport Security is one of the most effective mechanisms for enforcing secure communication between browsers and websites. By automatically upgrading future requests to HTTPS and preventing protocol downgrade attacks, HSTS significantly strengthens transport security. When combined with properly configured TLS, valid certificates and other security headers, HSTS provides an important layer of protection for modern web applications.