HSTS Preloading: Requirements, Risks, and How to Apply Correctly

HTTP Strict Transport Security (HSTS) is an HTTP response header that tells browsers to always use HTTPS when accessing a domain. HSTS preloading is a related but distinct mechanism that hardcodes the HTTPS requirement into browsers before any request is made. Understanding the difference matters because preloading has requirements and risks that plain HSTS does not.

HSTS vs. HSTS Preloading

Standard HSTS works after the first HTTPS visit. When a browser receives a Strict-Transport-Security header over an HTTPS connection, it caches the policy and refuses to connect to the domain over HTTP for the duration of max-age. The protection kicks in from the second visit onward.

The first visit is the gap. If a user types a domain into a browser address bar or clicks an HTTP link before they have ever visited the site over HTTPS, the first request goes out over HTTP. An attacker on the network path can intercept that request and redirect it to a malicious HTTPS site before the browser ever receives the HSTS header.

HSTS preloading closes this gap. Browsers ship with a hardcoded list of domains that must always be contacted over HTTPS, regardless of whether the browser has visited before. Chrome maintains the canonical list at hstspreload.org. Firefox, Safari, and Edge all use the same list. A domain on the preload list is protected from the very first request.

How the Preload List Works

Chromium (and the browsers that share its preload list) ships with a compiled list of domains stored in the browser binary. Adding a domain requires submitting it at hstspreload.org, passing the eligibility check, and then waiting for the entry to appear in a Chromium release and propagate to stable channel browsers.

The list is not queried at runtime. Entries are baked into the browser. This means that once a domain is on the preload list, every browser that shipped after the entry was added will enforce HTTPS for that domain, even if the domain later removes its HSTS header. Removal is possible, but it is slow.

Eligibility Requirements

To be eligible for the preload list, a domain must meet all of the following requirements:

• Serve a valid HTTPS response on the root domain (not just a redirect to HTTPS).
• Redirect all HTTP traffic to HTTPS, including the www subdomain if it is used.
• Serve a valid Strict-Transport-Security header on the HTTPS root domain response that includes all three of: max-age of at least 31536000 (one year), the includeSubDomains directive, and the preload directive.
• All subdomains must be accessible over HTTPS.

The required header format:

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

Note that includeSubDomains is mandatory for preloading. This means that once preloaded, every subdomain of the registered domain will be required to serve HTTPS. A subdomain that only serves HTTP will become unreachable.

Risks Before Submission

The preload directive in the HSTS header is a signal of intent, not an immediate action. Adding the directive to your header does not put you on the preload list. You still need to submit the domain at hstspreload.org. However, some security scanners and SEO tools flag the absence of preload as a finding, which can create pressure to add it before verifying readiness.

Before adding preload or submitting to the preload list, verify:

• Every subdomain you operate is accessible over HTTPS with a valid certificate. This includes staging environments, internal tools, API subdomains, and third-party service subdomains you control via DNS delegation.
• There are no subdomains that serve HTTP-only content and cannot be migrated to HTTPS in the foreseeable future.
• All wildcard certificate coverage is correct. A wildcard for *.example.com covers one level of subdomain only. It does not cover sub.sub.example.com.

If you are uncertain about subdomain coverage, the correct approach is to deploy HSTS without preload first and audit all subdomains before going further.

Step-by-Step Application Process

The recommended sequence for deploying HSTS and applying for preloading:

• Step 1. Confirm all subdomains are reachable over HTTPS with a valid, non-expired certificate.
• Step 2. Deploy HSTS with a short max-age initially (for example, 300 seconds) to test behavior without committing browsers long-term.
• Step 3. Monitor for any HTTP-only subdomains becoming unreachable.
• Step 4. Increase max-age to 31536000 and add includeSubDomains when you are confident all subdomains are HTTPS-ready.
• Step 5. Add preload to the header value.
• Step 6. Verify the header at hstspreload.org. If eligibility is confirmed, submit the domain.
• Step 7. Wait for inclusion in a Chromium release (typically several weeks to months after submission, depending on list update cycles).

Removal Is Slow

Removing a domain from the preload list requires submitting a removal request at hstspreload.org. The removal takes months to reach stable browser releases, and browsers shipped before the removal entry was added will continue enforcing HTTPS indefinitely. There is no way to immediately undo preloading for existing browser installations.

For this reason, preloading is best treated as a permanent commitment for a domain, not a configuration that can be easily reversed. Operate HSTS for an extended period without preloading first, and only proceed with the preload submission when you are confident the domain will remain HTTPS-only for the foreseeable future.

Verifying Your Configuration

Check that the HSTS header is present and correctly formed:

curl -sI https://example.com/ | grep -i strict-transport-security

The response should include the header with all three directives. Verify the header is served on the root domain over HTTPS, not just on subdirectory responses.

Check preload eligibility at hstspreload.org by entering your domain. The tool will evaluate your current HSTS configuration and report any issues blocking preload eligibility. It will also show your current preload status if already submitted.

To check whether a domain is already in the preload list compiled into Chrome, use the hstspreload.org checker or query the Chromium source preload list directly. The list is maintained in the Chromium repository at net/http/transport_security_state_static.json.

How WebDefect Flags HSTS Issues

WebDefect checks every HTTPS domain for the presence of a Strict-Transport-Security header. The check verifies:

• Whether the header is present at all on the root document response.
• Whether max-age meets the minimum recommended value of 31536000.
• Whether includeSubDomains is present (flagged as a finding if absent).
• Whether the header is served over HTTP (invalid HSTS delivery) rather than HTTPS.

A missing HSTS header on an HTTPS site is classified as a high severity finding because it leaves the site vulnerable to protocol-downgrade attacks on every visit that has not previously cached the policy.

References

• HSTS Preload List Submission, hstspreload.org
• Strict-Transport-Security, MDN Web Docs
• RFC 6797: HTTP Strict Transport Security (HSTS)