
Quick summary: HSTS is an HTTP response header that instructs browsers to always use HTTPS — permanently preventing SSL Stripping and Downgrade Attacks even on untrusted Wi-Fi networks.
What Is HSTS?
HSTS stands for HTTP Strict Transport Security. It is a web security policy delivered through an HTTP response header named Strict-Transport-Security. Once a browser receives this header, it remembers that the site must always be accessed over HTTPS and automatically refuses any HTTP connections to that domain for the duration of the max-age period.
In plain terms: even if a user types http://yourdomain.com, the browser converts it to https:// before the request ever leaves the device — giving attackers no window to intercept the connection.
Why Is HTTPS Alone Not Enough?
Having an SSL certificate does not fully protect users from SSL Stripping attacks. In an SSL Stripping attack, a man-in-the-middle intercepts the initial HTTP connection before the redirect to HTTPS happens, then silently proxies the traffic. The user sees HTTP while the attacker communicates with the server via HTTPS.
This attack is particularly effective on public Wi-Fi — airports, coffee shops, hotels — where users rarely examine the protocol in the address bar.
HSTS eliminates this window entirely: the browser never sends an HTTP request at all.
How HSTS Works
When a browser first connects to an HSTS-enabled site over HTTPS, the server sends back a header like:
The browser stores this policy, meaning:
- max-age=31536000 — Remember this for 1 year (31,536,000 seconds)
- includeSubDomains — Apply this policy to all subdomains too
For the next year, any request to http://yourdomain.com is silently upgraded to https:// by the browser itself — without a round-trip to the server.
Enabling HSTS on Apache (.htaccess)
For web hosting customers using Apache (such as AsiaGB Hosting on DirectAdmin), add the following to your .htaccess file:
To include HSTS Preload (explained below):
Important: Only enable HSTS once your SSL certificate is fully working. If SSL expires or breaks while HSTS is active, users will be completely locked out until max-age expires.
Enabling HSTS on Nginx
For VPS users running Nginx, add this directive inside your server block:
Enabling HSTS on WordPress
WordPress users can enable HSTS through the Really Simple SSL plugin or Wordfence Security — both have a toggle in their settings panel. Alternatively, any plugin that lets you set custom HTTP headers will work.
What Is HSTS Preload?
Standard HSTS has one limitation: on the very first visit to a site (before the browser has seen the HSTS header), there is still a brief window of vulnerability. HSTS Preload eliminates this by embedding your domain directly into a list that is shipped with Chrome, Firefox, Safari, and Edge.
To apply for HSTS Preload at hstspreload.org, your site must:
- Serve a valid SSL certificate for all subdomains
- Redirect all HTTP traffic to HTTPS (including subdomains)
- Serve an HSTS header with
max-ageof at least 31536000 - Include both
includeSubDomainsandpreloaddirectives
Key Warnings Before Enabling HSTS
- SSL must be valid at all times — An expired or broken certificate while HSTS is active means zero access for users.
- All subdomains need SSL — If you include
includeSubDomainsbut a subdomain lacks a certificate, it becomes unreachable. - Start with a short max-age — Begin with
max-age=300(5 minutes) to test, then gradually increase to 1 year. - HSTS Preload is hard to undo — Removal from the preload list takes months to propagate.
How to Verify HSTS Is Active
Method 1 — Browser DevTools: Press F12 → Network tab → click the first request → check Response Headers for Strict-Transport-Security.
Method 2 — Online checker: Visit securityheaders.com and enter your domain to see your security header grade.
Method 3 — Chrome HSTS Manager: Navigate to chrome://net-internals/#hsts and query your domain to see if Chrome has stored its HSTS policy.
Choosing the Right max-age Value
The max-age you choose directly controls the balance between security and flexibility. Too short and you lose protection; too long and a broken SSL certificate locks out all your visitors. The table below helps you pick the right value for your stage.
| max-age (seconds) | Equivalent | Best for | Recovery time if SSL breaks |
|---|---|---|---|
| 300 | 5 minutes | Initial testing | 5 minutes — very forgiving |
| 86400 | 1 day | Transition period | Up to 1 day |
| 2592000 | 30 days | Confident production sites | Up to 30 days |
| 31536000 | 1 year | Standard production | Up to 1 year — SSL must never expire |
| 63072000 | 2 years | Preload submission | Very difficult to undo |
HSTS and Your Website Security Score
Beyond blocking attacks, HSTS improves your site's security score across multiple evaluation frameworks. Tools such as securityheaders.com award an A or A+ grade when HSTS is present alongside complementary headers like Content-Security-Policy, X-Frame-Options, and Referrer-Policy. Google also factors security signals into its crawl and ranking evaluations.
For e-commerce or any site that handles payment data, HSTS is part of the PCI DSS (Payment Card Industry Data Security Standard) requirements. Compliance mandates that HTTP connections be permanently blocked — HSTS is the correct technical mechanism to enforce this at the browser level without relying solely on server-side redirects.
If you use a tool like dnsxray.com to run a security headers check on your domain, you will see the exact HSTS header your server is sending — including the max-age value, whether includeSubDomains is set, and whether your site qualifies for Preload submission.
Common HSTS Mistakes to Avoid
HSTS configuration is straightforward, but several common mistakes can cause either zero protection or locked-out visitors.
- Sending the HSTS header over HTTP — Browsers completely ignore HSTS headers delivered over plain HTTP. The header must come from an HTTPS response.
- Forgetting mod_headers on Apache — Without the headers module loaded,
Header always sethas no effect. Verify withapache2ctl -M | grep headers. - Adding includeSubDomains before all subdomains have SSL — Any subdomain without a valid certificate instantly becomes unreachable to browsers that have cached the HSTS policy.
- Removing the header to "undo" HSTS — Simply removing the header does nothing for browsers that already cached the policy. You must serve
max-age=0to instruct browsers to clear the stored entry. - Combining preload with a short max-age — hstspreload.org requires max-age of at least 31536000. A short max-age with the preload directive will be rejected.
Summary: Should You Enable HSTS?
If your site has a valid SSL certificate on every subdomain — yes, enabling HSTS is strongly recommended. It closes the only remaining window that SSL alone cannot protect: the very first HTTP request before the server redirect kicks in.
The recommended path: (1) Install a trusted SSL certificate → (2) Force HTTP to HTTPS redirect → (3) Add the HSTS header with max-age=300 → (4) Test with securityheaders.com → (5) Gradually increase max-age to 1 year → (6) Add the preload directive and submit to hstspreload.org when ready.
Get a Trusted SSL Certificate from AsiaGB
RapidSSL from ฿1,000/yr · GeoTrust · DigiCert · Issued in 5 minutes
Compatible with HSTS and HSTS Preload on all major browsers