Frequently Asked Questions

General

What does the `Strict-Transport-Security` header mean?

A Strict-Transport-Security header contains a domain's HSTS policy. It specifies a max-age of how many seconds a browser should remember to connect to the domain only over HTTPS. It can optionally contain a includeSubDomains directive that indicates that the policy should apply to subdomains as well. This site also defines the preload directive, which is used to indicate that the domain is requesting inclusion in the HSTS preload list. For example, suppose example.com sends the header Strict-Transport-Security: max-age=31536000; includeSubDomains on all of its HTTP responses. A web browser that receives this header will remember for 1 year (31536000 seconds) to upgrade all requests to example.com and its subdomains to HTTPS.

For more information on the Strict-Transport-Security header, see this MDN article or RFC 6797.

Scanning results from hstspreload.org

The hstspreload.org scanner is displaying an error for my domain. What do I need to do?

The form on hstspreload.org is not intended as a web security scanner or to provide judgement on how secure a website is. An error for a domain on hstspreload.org does not mean that there are any security issues with that domain. The sole purpose of hstspreload.org's form is to request that a domain be included on the HSTS preload list, and the sole purpose of its error messages is to act as a diagnostic tool. No action is required in response to errors listed on hstspreload.org.

Other tools report that my domain is sending the HSTS header, but hstspreload.org doesn't. Is something wrong with hstspreload.org?

Some popular web security scanning tools will report the headers seen after following all redirects. The hstspreload.org scanner requires that the Strict-Transport-Security header be present on the first HTTP response, even if that response is a redirect and the page it redirects to has the Strict-Transport-Security header on its response. A common configuration mistake is that example.com is configured without the Strict-Transport-Security header and redirects to www.example.com which does send the header.

The difference in results between what hstspreload.org displays and other tools is due to checking for different things.

Preloading

My domain has been pending submission for a few weeks now. How long should it take for it to be added to the preload list?

It is normal for your domain to be pending submission for a few weeks. The preload list is updated once every Chrome release, which is approximately every 4 weeks. Submitting a domain to be preloaded is the last step of a long deployment process that starts with gradually ramping up the max-age of the Strict-Transport-Security header. There is no need to rush this last part of the process.

If your domain has been pending submission for over 8 weeks, check the configuration of your site. Before a domain is added to the preload list, its eligibility is verified a second time. If your server's configuration has changed, or if your server's configuration does anything to special-case the hstspreload.org infrastructure, it could be failing this second verification check.

I'm trying to preload my domain but hstspreload.org is showing an error. How do I fix it?

The error message should indicate what needs to change to meet the preloading requirements. Common configuration mistakes include not sending the Strict-Transport-Security header on all responses or only configuring the header for the www subdomain. The Strict-Transport-Security header must be sent on all responses for your domain, including redirects. It must be configured on the bare domain (e.g. example.com) and not just the www subdomain, even if you redirect from e.g. example.com to www.example.com.

Other configuration errors include configuring a firewall to reject requests before the Strict-Transport-Security header has been added to the response, or to condition the presence of the Strict-Transport-Security header on the User-Agent sent by the client.

Can you help me configure my domain to resolve an issue with a specific error from hstspreload.org?

Every web server stack is different, so we can't provide advice on how to configure a specific server or help you debug your setup. See the above answers for general advice. We will not respond to questions asking for help configuring your domain.

What regions or locations should I unblock so that my geographically restricted website can be preloaded?

We expect that domains on the HSTS preload list are broadly available and accessible to browser end-users. If you are blocking access to your domain in certain regions, then your domain is not a good candidate for inclusion on the HSTS preload list. You can still set an HSTS policy for your domain without preloading it, and most of the benefit comes from enabling HSTS rather than the additional step of preloading.

What IP addresses should I unblock on my WAF or other firewall to allow hstspreload.org to scan my domain?

We expect that preloaded domains are broadly accessible, and we do not provide a list of IP addresses to allowlist or other firewall configuration advice.

Authenticating requests to preload

Why is there no authentication on the form to preload a domain?

Requests to preload a domain are authenticated by verifying the server's TLS certificate and authorized by the presence of the preload directive on the Strict-Transport-Security header sent over HTTPS. No additional authorization is needed. RFC 6797 specifies that the Strict-Transport-Security header instructs browsers to upgrade all requests to HTTPS with only the TLS certificate used for authentication; HSTS preloading has the same effect of upgrading requests to HTTPS and is authenticated in the same way.

My domain was added to the HSTS preload list but no one at my company requested that it be added. Who added it? Where did the request come from?

We're unable to provide information about where the request to preload a domain came from. To determine where the request came from, review your change management system for the configuration of the web server(s) handling requests to the bare domain, and look for changes to the Strict-Transport-Security header.

Removal

How do I protect my domain from removal from the HSTS preload list?

To keep your domain from getting removed from the HSTS preload list, it must continue to meet the requirements for preloading. We understand that sites occasionally have outages, so temporary outages won't result in removal. However, if the site is unavailable for an extended period of time or otherwise doesn't meet the continued requirements, it may be removed from the list. If your domain serves a Strict-Transport-Security header without the preload directive, it may be eligible for immediate removal.

How do I remove my domain from the HSTS preload list?

To remove your domain from the HSTS preload list, use the form at hstspreload.org/removal. To be eligible for removal, your domain needs to send a valid Strict-Transport-Security header that doesn't contain the preload directive.

How long does it take to process a removal request?

Removals are processed at the same speed as additions to the list. Once a removal has been processed, expect it to take several additional months before the domain is no longer preloaded in most users' browsers.

My domain (or one of its subdomains) is broken due to preloading, and waiting for it to be removed from the preload list is taking too long. What else can I do?

The quickest and easiest fix is to configure the webservers on your domain (and its subdomains) to serve HTTPS with a valid TLS certificate. Another option is to configure a different domain name to point to the same servers and access HTTP resources via that domain. If breakage is due to old clients that can't connect via HTTPS, you can configure the server to not redirect HTTP to HTTPS while waiting for the removal to process.

If you noticed breakage of your domain or one of its subdomains due to HSTS preloading, the cause of the breakage is due to an issue with the HSTS policy. When removing the preload directive from the Strict-Transport-Security header, you should change the corresponding issue with the HSTS policy as well, e.g. removing includeSubDomains or setting a knockout entry to disable HSTS entirely (e.g. Strict-Transport-Security: max-age=0).