HTTP Strict Transport Security (HSTS) is a security header that instructs browsers to only connect to a website via HTTPS, never over HTTP. It prevents SSL stripping attacks, man-in-the-middle attacks, and ensures all communication is encrypted. Without HSTS, a user's first request might go over unencrypted HTTP before being redirected, creating a window of vulnerability.

The max-age directive specifies (in seconds) how long the browser should remember that the site must only be accessed via HTTPS. Common values: 31,536,000 (1 year), 63,072,000 (2 years). A longer max-age provides better security. Google's HSTS preload list requires a minimum max-age of 1 year (31,536,000 seconds), with 2 years recommended.

The includeSubDomains directive extends the HSTS policy to all subdomains of the main domain. For example, if example.com sets HSTS with includeSubDomains, then blog.example.com, api.example.com, and all other subdomains must also be accessed via HTTPS. This prevents attackers from targeting unprotected subdomains.

HSTS Preload is a list of domains hardcoded into browsers (Chrome, Firefox, Safari, Edge) that are enforced to use HTTPS from the very first request — even before the HSTS header is received. To enable preloading, add the preload directive to your header and submit your domain at hstspreload.org. Requirements: valid certificate, redirect HTTP→HTTPS on the same host, all subdomains covered, and max-age ≥ 1 year.

You can verify HSTS in several ways: (1) Use this tool to check the response headers; (2) Open browser DevTools → Network tab → click the main request → look for strict-transport-security in Response Headers; (3) Visit hstspreload.org to check preload status; (4) Use command-line tools like curl -I https://yoursite.com and look for the header.

• Too-short max-age: Using a very short max-age (e.g., a few hours) defeats the purpose — the browser forgets the policy quickly.
• Missing includeSubDomains: Attackers can target unprotected subdomains.
• Setting HSTS on HTTP response: HSTS headers on HTTP responses are ignored by browsers (per RFC 6797).
• Forgetting about preload removal difficulty: Once in the preload list, removal can take months. Ensure your HTTPS setup is stable before submitting.
• Not testing subdomains: All subdomains must have valid HTTPS when using includeSubDomains.

Nginx:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Cloudflare: Enable HSTS in SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS).

Node.js (Express): Use the helmet middleware — app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true, preload: true })).

HSTS significantly improves security but is not 100% foolproof. The first visit to a site (before the HSTS header is received) is still vulnerable — this is called the "Trust on First Use" (TOFU) problem. The HSTS Preload list solves this by shipping HSTS rules directly inside browser code. Additionally, if the client's clock is incorrect, max-age calculations may be affected. Overall, combining HSTS with preloading, proper certificate management, and HTTPS-only cookies provides robust protection.

A simple HTTPS redirect (301/302) only redirects after the initial HTTP request has already been made — leaving a window for attackers to intercept. HSTS tells the browser before any request that this domain must use HTTPS, eliminating the vulnerable initial HTTP request entirely (after the first visit, or immediately if preloaded). HSTS also prevents users from clicking through SSL certificate warnings.

You should test your HSTS configuration: (1) After initial setup; (2) After any server configuration changes; (3) After SSL/TLS certificate renewal; (4) Periodically (monthly) as part of your security audit routine; (5) Before submitting to the preload list; (6) After adding new subdomains. Regular checks ensure your security posture remains strong and catch configuration drift early.