HTTPS has become the default for the modern web. But HTTPS alone is not enough. There is a window where users can still end up on HTTP versions of sites, or be tricked into HTTP connections by attackers. HSTS closes that window.
HTTP Strict Transport Security, usually called HSTS, is a security header that tells browsers to always use HTTPS for your site. Once the browser sees the HSTS header, it remembers and refuses to make HTTP connections to your site for a specified period.
This piece covers what HSTS actually does, why it matters even with HTTPS already in place, how to enable it safely, and the pitfalls that can cause problems if you implement it without care.
What HSTS Does
HSTS is a security header that enforces HTTPS at the browser level.
How HTTPS Works Without HSTS
Without HSTS, users can still reach your site over HTTP. They type a URL without specifying HTTPS. They click an old link to the HTTP version. They get redirected from another HTTP site.
When this happens, your server probably redirects them to HTTPS. The browser follows the redirect. The final connection uses HTTPS.
The problem is the initial HTTP connection. During that brief moment, an attacker on the network could intercept the request and tamper with it. The browser would never reach your HTTPS site.
How HSTS Changes Things
When HSTS is enabled, your server tells browsers: “Always use HTTPS for my site. Never make HTTP requests to me.”
The browser remembers this instruction. The next time the user tries to reach your site, the browser uses HTTPS automatically. Even if the user types HTTP. Even if a link points to HTTP. Even if a script tries to load HTTP resources.
The window of vulnerability gets closed.
The Security Improvement
HSTS specifically protects against several attacks:
SSL stripping attacks where attackers intercept the initial HTTP request and prevent the upgrade to HTTPS.
Mixed content attacks that load HTTP resources on HTTPS pages.
Cookie theft through unencrypted connections.
Man-in-the-middle attacks on local networks (coffee shops, hotels, conferences).
For sites that handle sensitive data, the protection is meaningful.
How HSTS Actually Works
The mechanism is straightforward but has some details worth knowing.
The HSTS Header
The header looks like this:
Strict-Transport-Security: max-age=31536000
The max-age value tells the browser how long to enforce HTTPS, measured in seconds. 31536000 is one year.
After receiving this header, the browser will use HTTPS for your site for one year, regardless of how the user tries to reach it.
Including Subdomains
By default, HSTS only applies to the domain that sent it. To extend protection to subdomains:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This applies HSTS to your main domain and all subdomains. Useful when you have many subdomains and want consistent protection.
Be careful with this directive. If you have subdomains that do not support HTTPS, includeSubDomains will break them. Make sure all subdomains have proper HTTPS before adding this.
Preload
Browsers can include domains in a preload list. Sites on the list have HSTS enforced from the first visit, before the browser has ever received the HSTS header.
Adding the preload directive signals interest in inclusion:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Then you submit your domain to the HSTS preload list at hstspreload.org.
Preload provides maximum protection but is essentially permanent. Removing a site from the preload list takes time and effort.
The HSTS Trade-Off
HSTS is powerful but comes with trade-offs.
Once Set, Hard to Reverse
When HSTS is set, browsers enforce HTTPS for the max-age duration. If your HTTPS breaks during this time, users cannot reach your site at all.
The browser will not fall back to HTTP. The browser will not bypass certificate errors. The browser will not let users override the policy.
This is intentional. The point of HSTS is to enforce HTTPS strictly. But it means HTTPS problems become more severe.
Certificate Issues Become Critical
Without HSTS, an expired or invalid certificate generates a warning that users can sometimes click past. With HSTS, the browser refuses the connection entirely.
Certificate renewal becomes more important. Monitoring becomes more important. Backup certificates become more important.
Preload Is Essentially Permanent
Once your domain is in the preload list, removal takes months at minimum. Browsers update their preload lists slowly. Removal involves multiple steps.
Only preload domains where you are committed to HTTPS forever.
How to Enable HSTS Safely
The recommended approach is gradual.
Verify HTTPS Is Solid First
Before enabling HSTS, make sure HTTPS works correctly across your entire site. Test:
The main domain.
All subdomains you want to include.
All pages, not just the home page.
Resources loaded by pages (images, scripts, fonts).
External services that integrate with your site.
If anything fails over HTTPS, fix it before enabling HSTS.
Start With Short Max-Age
Begin with a short max-age value, like 300 seconds (5 minutes):
Strict-Transport-Security: max-age=300
If something is wrong, the impact is limited to 5 minutes. Users who reach the site during the bad period only have HSTS enforced briefly.
Verify Everything Works
After enabling with short max-age, verify the site still works correctly. Test various scenarios. Check that HTTPS is being enforced as expected.
If issues appear, you have time to fix them before HSTS persists.
Gradually Increase Max-Age
Once short max-age works fine, increase to a longer duration. Common steps:
300 seconds (5 minutes).
3600 seconds (1 hour).
86400 seconds (1 day).
604800 seconds (1 week).
2592000 seconds (1 month).
31536000 seconds (1 year).
Each step lets you verify everything is still working before committing to a longer duration.
Add includeSubDomains When Ready
After the main domain is solid with HSTS, evaluate whether to add includeSubDomains. Verify all subdomains support HTTPS before doing so.
Consider Preload After Long-Term Success
Preload is the maximum protection but the strongest commitment. Only preload after running HSTS successfully for an extended period, and only if you are committed to HTTPS forever.
Implementing HSTS
The actual configuration depends on your platform.
Apache
Add to .htaccess or virtual host configuration:
Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”
The “always” keyword ensures the header gets sent even for error responses.
Nginx
Add to server configuration:
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;
WordPress
Plugins handle HSTS for WordPress users who do not have server access. Really Simple SSL Pro and similar plugins include HSTS configuration.
Cloudflare
Cloudflare lets you enable HSTS through its dashboard. Cloudflare > SSL/TLS > Edge Certificates > HTTP Strict Transport Security.
This works regardless of your origin server configuration.
Other Platforms
Most modern web platforms have ways to configure HSTS. Check your platform’s documentation.
Testing HSTS
After enabling, verify it works.
Browser Developer Tools
Open the Network tab. Look at response headers for your site. Confirm the Strict-Transport-Security header appears with your configured values.
Online Testing Tools
SSL Labs (ssllabs.com/ssltest/) provides comprehensive HTTPS testing including HSTS verification.
Security Headers (securityheaders.com) shows your security header configuration.
Verifying Enforcement
Try visiting your site over HTTP after the browser has seen HSTS. The browser should upgrade to HTTPS without making the HTTP request.
You can verify this by checking the address bar and the network requests.
Recovering from HSTS Problems
If HSTS causes issues, recovery is involved.
Short Max-Age Helps
If you started with a short max-age, problems resolve themselves quickly. The HSTS expires, and users can reach the site over HTTP again.
This is why starting with short max-age is recommended.
Long Max-Age Means Waiting
If you set a long max-age and your HTTPS breaks, affected users cannot reach the site until either:
The HSTS expires (after max-age seconds).
You fix the HTTPS issue.
The user clears their HSTS settings (most users do not know how).
This is why having solid HTTPS is essential before long max-age values.
Browser HSTS Settings
Most browsers have a way to clear HSTS for specific sites. Chrome: chrome://net-internals/#hsts. Firefox: about:networking#hsts.
But asking users to clear their browser settings is impractical at scale.
Disabling Your HSTS Header
You can disable HSTS by sending a max-age=0 header:
Strict-Transport-Security: max-age=0
This expires HSTS for the user immediately. But this only affects users who receive the new header. Users who cannot reach the site (because HTTPS is broken) cannot receive any header.
Common HSTS Mistakes
People stumble in predictable ways.
Enabling Immediately With Long Max-Age
The most common mistake. Enable HSTS with a one-year max-age before fully testing HTTPS. Then HTTPS breaks somewhere unexpected, and users are locked out.
Always start with short max-age.
Forgetting Subdomains
Enable includeSubDomains when some subdomains do not have HTTPS. Those subdomains become unreachable.
Preloading Too Early
Submit a domain to the preload list before being committed to HTTPS forever. Then realize you need to change something and the preload is essentially permanent.
Only preload after careful consideration.
Not Monitoring Certificates
After HSTS, expired certificates have severe consequences. Without HSTS, expired certificates generate warnings. With HSTS, they block all access.
Certificate monitoring becomes essential.
Mixed Content After HSTS
After HSTS, browsers refuse to load HTTP resources on HTTPS pages. Sites with mixed content suddenly have broken images, missing scripts, or broken styles.
Audit and fix mixed content before enabling HSTS.
Closing Thoughts on Forcing Secure Connections
HSTS is one of those security measures that provides meaningful protection with modest implementation effort, but it requires care to avoid breaking things.
For most modern sites with HTTPS already in place, enabling HSTS is the right next step. The protection against the remaining HTTP vulnerabilities is real. The implementation is just a header configuration.
The key is the gradual approach. Start with short max-age. Verify everything works. Increase gradually. Eventually reach the standard one-year duration. Consider preload only after long-term success and commitment.
Sites that have implemented HSTS well are protected against an entire category of attacks that sites without HSTS still face. SSL stripping, HTTP downgrade attempts, mixed content vulnerabilities. The protection persists across all users.
For sites that handle any sensitive data (payment information, user accounts, business data), HSTS should be standard practice. The cost of implementation is small. The protection added to the existing HTTPS investment is meaningful.
If your site has HTTPS but not HSTS, evaluating whether to add HSTS is worthwhile. Test HTTPS thoroughly. Start with short max-age. Move gradually toward standard durations. The investment is a few hours of careful work. The protection lasts forever after. Sites that follow modern security practices include HSTS. The absence of HSTS on HTTPS sites is increasingly a sign of incomplete security configuration rather than a deliberate choice. The work to add it is bounded. The improvement is concrete.
