HSTS: Close Your Site's Security Gap

December 11, 2025•5 min read

Cover image - a stylized padlock centered over a digital network, symbolizing HTTPS

Web security has come a long way over the last decade, transforming from simple password protection and basic encryption to complex ecosystems designed to protect against sophisticated attacks. Despite progress in web security, many attacks continue to target the fundamental HTTP protocol weakness by silently downgrading connection or intercepting traffic before it even reaches an encrypted channel. HTTP Strict Transport Security (HSTS) was designed to fill that gap.

HSTS is just a response header, but the implications of using it are profound. It strengthens the security posture of HTTPS-enabled sites, prevents downgrade attacks, and ensures a consistent, fully encrypted experience.

By the end of this article, you'll have a clear, practical understanding of HSTS and how to implement it responsibly on your own site.

What HSTS Is and the Problem It Solves

At its core, HSTS is a policy that tells the browser to use HTTPS only, with no fallback to HTTP. Once received, the browser enforces this rule for a specified period, ensuring that no future attempts to load the domain over HTTP will succeed - even if an attacker tries to manipulate the connection. The browser automatically upgrades all HTTP requests to HTTPS for the duration of the policy.

Why is it important if most sites already redirect HTTP to HTTPS? Because redirects rely on the assumption that the attacker will not interfere. For example, if someone is on an insecure public Wi-Fi network, a malicious actor can intercept an HTTP request and strip the redirect to HTTPS. This type of attack, known as SSL stripping, allows the attacker to establish unencrypted connections, conduct man-in-the-middle (MITM) attacks where they can read data or inject malicious content.

HSTS eliminates this vulnerability by ensuring the browser never attempts an HTTP connection. Once the policy is set, the browser strictly honors it.

How HSTS Works Behind the Scenes

To enable HSTS, a web server must include the Strict-Transport-Security header in its HTTPS responses. The first time a user visits the site over HTTPS, their browser receives this header and stores the security policy locally. This policy is enforced for all subsequent visits for the duration specified in the max-age directive. During that period, any attempt to access the domain with http:// is automatically rewritten to https:// before any request is sent, preventing insecure connections. This behavior can also be applied to subdomains if the includeSubDomains directive is included in the header.

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

max-age is the number of seconds the browser should enforce HTTPS-only communication. It's smart to start with something short, such as a few hours, for initial testing. Once you confirm no functionality breaks, you can safely increase it.
includeSubDomains extends the HTTPS enforcement rule to every subdomain under your main domain. Before enabling it, you need to confirm that all subdomains support HTTPS and serve the HSTS header correctly. A single overlooked subdomain that isn't HTTPS-compliant will break access for all users.

If the site sends the header again before expiration (for example, the user visits it again), the policy duration is renewed, ensuring continuous protection.

However, this implementation has a significant drawback. The browser starts enforcing HTTPS for future visits only after receiving an HSTS header from an HTTPS response. But often users visit websites by entering a domain name in the browser without specifying HTTPS protocol. In this case the browser assumes they want to connect over HTTP. During this initial unencrypted connection, an attacker can intercept traffic. The HSTS Preload List addresses this critical first-request problem that weakens HSTS enforcement.

The HSTS Preload List

The preload list is a centralized set of domains shipped directly inside browsers like Chrome, Firefox, Safari, and Edge. When a domain is preloaded:

The browser treats it as HTTPS-only, even on the very first visit.
Downgrade attacks are impossible from the very first visit.
Users cannot accidentally access the domain insecurely.

Requirements to Be Preloaded

To qualify, your site must:

Serve a valid HTTPS certificate.
Redirect all HTTP requests to HTTPS.
Include the Strict-Transport-Security header with a long max-age (minimum 1 year).
Ensure all subdomains also use HTTPS and apply HSTS to all subdomains via includeSubDomains directive.
Include the preload directive in the header.

These requirements ensure your site maintains consistent HTTPS enforcement before being added to the preload list.

In a significant shift toward a secure-by-default web, Google Registry launched an initiative to add entire top-level domains (TLDs) to the HSTS Preload List. This approach reached mainstream adoption with .app in 2018 and .dev in 2019 - domains designed for developers, tech companies, and software projects that provide professional branding with mandatory HTTPS enforcement.

Advantages and Disadvantages of Preloading

Preloading provides complete first-visit protection with persistent HTTPS enforcement that cannot be bypassed, even by misconfigured redirects and serves as a strong trust signal for users and security auditors.

However, implementing preloading on existing projects can be challenging. You may have legacy services or subdomains that only work over HTTP. Once a domain is preloaded, you cannot easily remove it from the browser's built-in list. There is no test-drive period - if you make a mistake, removal from the list may take months to propagate across browsers and isn't guaranteed. Make sure you don't have any subdomains that work over HTTP only, or you can lock yourself out if you miss anything.

To implement HSTS, you can set the Strict-Transport-Security header in server-side environments such as Node.js, or in web servers like Nginx or Apache. Many content delivery networks, such as Cloudflare, provide simplified methods of activating HSTS through their dashboards without modifying server configurations directly. This makes it easier to implement comprehensive HTTPS security across all edge locations.

A Safe Step-by-Step Deployment Strategy

A careful rollout minimizes risk and ensures predictable behavior.

Step 1: Confirm Full HTTPS Compatibility.

Make sure:

Your certificate is valid and current.
All resources load over HTTPS.
No mixed-content warnings appear.
All external dependencies support HTTPS.

Step 2: Introduce HSTS with a Short max-age. Testing with short durations allows you to confirm everything works before committing.

Strict-Transport-Security: max-age=3000

Increase max-age if no issues found. Remember that any browser that visits your site during this time saves the HSTS configuration locally. If something goes wrong and you need to roll back HSTS, those browsers will fail to open your site until the max-age period expires or until the user manually clears the HSTS policy in their browser.

Step 3: Add includeSubDomains Directive Only do this after ensuring all subdomains are HTTPS-compliant.

Step 4: Add preload When Fully Confident Once the domain and subdomains are ready, add the preload directive and submit to the preload list.

Testing and Verification

To confirm your configuration is correct before submitting to the preload list, use browser Developer Tools or curl to inspect response headers and ensure the HSTS header is present and correctly formatted.

curl -I https://example.com

Look for the Strict-Transport-Security header in the output. Services like SSL Labs or SecurityHeaders can also check your HSTS configuration and identify other TLS issues.

HSTS in the Broader Security Ecosystem

HSTS is most effective when combined with other modern security standards. Follow best practices for TLS hardening, Content Security Policy, and zero-trust web security. Keep in mind that HSTS is not a universal solution. It doesn't protect metadata or fix mixed content automatically. If a domain isn't preloaded, the first visit remains vulnerable to attacks.

Conclusion

HSTS is one of the simplest and most impactful improvements you can make to web security. It eliminates downgrade attacks and ensures a reliable, encrypted experience for users. Implementing it requires awareness of its implications, particularly around subdomains and the preload list, but once configured correctly, it provides long-term, stable protection with minimal ongoing effort.

For any site serious about security and user trust, HSTS should be a standard part of your security configuration.