A Basic Overview of HSTS Preload List
The HTTP Strict Transport Security (HSTS) Preload List is a key security feature in Google Chrome and other Chromium-based browsers. It significantly enhances HTTPS security by forcing connections to websites on the list to always use HTTPS, even on the very first visit.
While normal HSTS policies require one successful HTTPS connection to enable strict transport security, the HSTS Preload List hardcoded into Chrome bypasses this requirement. This prevents network attacks like SSL stripping that intercept the initial HTTP connection attempt.
However, the HSTS Preload List has downsides, too. Once added, websites can’t be easily removed, so it requires a long-term HTTPS commitment. Improper implementation can break site functionality or cause certificate warnings.
This guide covers everything about the HSTS Preload List in Chrome—what it is, how it works, its benefits and downsides, eligibility criteria, and step-by-step instructions for adding your website domain.
Key Takeaways
- The HSTS Preload List is a hardcoded list of websites in Chrome that enforces HTTPS connections.
- Adding a domain to the HSTS Preload List forces Chrome to only connect to that domain using HTTPS, even on the first visit.
- To add a domain to the HSTS Preload List, you need to meet certain criteria, such as having valid HTTPS and enabling HSTS on the domain.
- After meeting the requirements, you can submit the domain through Chromium’s web form for inclusion in the HSTS Preload List.
- Once added, it takes months to years for the domain to be activated in the list, as Chrome only updates it with new major version releases.
- HSTS Preload helps prevent SSL stripping attacks and accidental HTTP connections but also has downsides, like being difficult to remove from the list.
What is the HSTS Preload List in Chrome?
The HSTS, or HTTP Strict Transport Security Preload List, is a list of websites that are hardcoded into Chrome, Chromium, and other browsers based on Chromium.
For each domain on the HSTS Preload List, these browsers will:
- Only allow connections over HTTPS, even on the very first visit.
- Automatically convert HTTP connections to HTTPS.
- Users are not allowed to override invalid certificate errors.
This enforces secure HTTPS connectivity and prevents users from accidentally visiting the HTTP version of sites.
The HSTS Preload List aims to thwart network-based downgrade attacks, such as SSL Stripping, which intercepts the initial insecure HTTP connection attempt and replaces certificates.
On later visits, the site’s own HSTS policy will kick in to enforce HTTPS. But the preload list protects even the first visit.
How Does the HSTS Preload List Work?
The HSTS Preload List works by creating a hardcoded HSTS rule for each website inside Chrome, Chromium, and other relevant browser source code.
Whenever the browser attempts to connect to a site that’s on the preload list, even the very first time, it will:
- Automatically redirect the connection from HTTP to HTTPS if the site is accessed over HTTP.
- Refuse to connect over HTTP and return an error if the initial request uses HTTP.
- Reject any invalid certificates and do not allow users to click through certificate warnings.
So, the first visit is protected just like later visits where the site’s own HSTS header would kick in.
This happens automatically, with no need for the site’s server to send the HSTS response header. The browser’s hardcoded list overrides the lack of an HSTS header on the first visit.
Once a domain is added to the list, it can take months to years for it to be activated. The HSTS Preload List has only been updated alongside major browser version releases.
To remove a site, Chromium developers have to manually update the source code to delete entries from the list before the next release.
What the Major Benefits of the HSTS Preload List
Adding domains to the HSTS Preload List in Chrome provides these key security benefits:
Protection Against SSL Stripping
The main benefit of the HSTS Preload List is it thwarts SSL Stripping attacks.
SSL Stripping exploits the unencrypted initial HTTP connection to a website that hasn’t sent the HSTS header previously. The attacker intercepts this HTTP request and replaces the site’s SSL certificate with their own.
However, domains on the preload list are hardcoded to use HTTPS, so the initial request is secure for preloaded sites.
No Accidental HTTP Connections
Another advantage is it prevents users from ever accidentally connecting over HTTP.
With preload, honest typos or HTTP links could lead users to the secure HTTP version of sites. The preloaded HSTS rule kicks in to correct this.
UX Improvement on Initial Visit
The preload list spares users from certificate warnings or mixed content errors on their very first visit to a site.
The seamless redirect from HTTP to HTTPS happens invisibly in the background rather than disrupting the user’s first visit.
Performance and Reliability Benefits
Requiring HTTPS connections upfront avoids performance issues and instability caused by protocol upgrades from HTTP to HTTPS.
Simpler HSTS Implementation
Site owners don’t need to worry about successfully sending the HSTS header before getting HSTS protection. Preloading acts as a fallback for sites that have difficulty setting HSTS headers.
What are the Downsides of the HSTS Preload List
While the HSTS Preload List improves security and performance, adding a domain has downsides too:
Difficulty Removing Sites
Once added, sites can’t be easily removed from the list. Chromium developers have to update the source code to manually delist a domain.
This makes HSTS preloading a long-term commitment to supporting HTTPS.
Risk of Breaking Functionality
For sites not 100% HTTPS, preloading can break site functionality that relies on HTTP connections. Frontend JavaScript, APIs, and images not migrated to HTTPS can fail.
Inflexibility
HSTS preloading removes the flexibility to redirect some traffic to HTTP or disable HSTS temporarily intentionally, for example, for maintenance or emergency fallback to HTTP.
Locked into Domain Names
The HSTS Preload List binds domains to their exact names on the list. Renaming requires reapplying with the new domain name.
Due to these downsides, HSTS preloading might only be suitable for some sites and applications, especially ones with HTTP legacy dependencies.
What are the Requirements of HSTS Preload List
To be eligible for inclusion in Chrome’s HSTS Preload List, websites must meet these requirements:
- Active HTTPS: Serve a valid TLS certificate and redirect HTTP to HTTPS.
- HSTS enabled: You already sent the HTTP Strict Transport Security header to your site.
- Include subdomains: The HSTS header must cover the whole domain: both apex and subdomains.
- Minimum duration: HSTS max-age must be at least 1 year (31536000 seconds).
- No RSS: Domain has no RSS or feed endpoints that rely on HTTP traffic.
- Canonical DNS: The site uses the canonical DNS hostname format without non-standard ports, URL paths, etc.
- Respect preferences: Allow users to opt out of HTTPS connections if explicitly chosen in browser settings.
Step-by-Step Guide to Add a Domain to Chrome’s HSTS Preload List
Follow these steps to submit a domain to the HSTS Preload List:
Ensure the Site Meets the Requirements
First, thoroughly review the HSTS preloading requirements and ensure your site meets them.
Pay particular attention to enabling HSTS with a long max-age and include SubDomains across the entire domain.
Check HSTS Deployment
Confirm proper HSTS functionality using the HSTS Preload Ready Test.
List HTTPS Endpoints
Make a list of all HTTPS site endpoints and subdomains for reference while preloading.
Fill Submission Form
Go to the HSTS Preload List submission form and fill it with your domain and contact details.
Wait for Review
After submission, Chromium developers will manually review the domain and may contact you with any queries.
This review aims to verify all requirements are properly met.
Preload Activation
Once approved, the domain is added to the source code of the next major Chrome release, which can take months to years.
You’ll receive an email when the submitted domain is live on the preload list.
How to Check Status of HSTS Preload
To check the status of a domain’s HSTS preloading, use these methods:
- The HSTS Preload request database shows submitted domains and their status.
- If a site is on the HSTS Preload List, the Chrome DevTools Security panel displays “Preloaded” under the Origin.
- The Chrome Platform Status site shows upcoming changes to the preload list in upcoming Chrome versions.
- The Can I Use website indicates if a domain is preloaded in major browsers, such as Chrome, Firefox, Safari, etc.
- The Mozilla Observatory scan results include the HSTS preload status for a domain.
- Testing directly: Try visiting the site in Chrome over HTTP and check if it gets redirected to HTTPS without any prompt or error.
Troubleshooting HSTS Preloading Issues
Some common issues faced when preloading domains and troubleshooting tips:
- The site is broken after preloading. If functionality breaks, check for any HTTP-only endpoints that are now blocked. Fix or exclude those paths.
- If the subdomain is not working, ensure the HSTS header applies to the whole domain, including the apex and subdomains.
- Errors on HTTP: If HTTP versions throw errors, it indicates preload is active. Verify HTTPS availability.
- Delays in preloading: Check upcoming Chrome releases for preload list updates if activation is taking too long.
- Removal issues: If delisting is urgent, Request the Chromium team to remove domains manually. However, removal can also take months.
- HTTPS redirection problems: Confirm redirection from HTTP to HTTPS works properly without any cert errors.
- HSTS headers missing on renewals: Some CDNs may drop HSTS headers on certificate renewals. Check and re-enable if needed.
HSTS Preloading Best Practices
Some tips for securely preloading domains:
- Fully test site functionality on HTTPS before preloading. Fix any broken HTTP endpoints.
- Adopt strong 2048+ bit encryption, up-to-date TLS versions, and perfect forward secrecy.
- Pick a very long HSTS max-age, like 1-2 years, with an include Sub-domains set.
- Renew SSL certificates well in advance of expiration to avoid intersection with preloading.
- Specify the canonical name as the domain without non-standard ports, paths, etc.
- Try to consolidate subdomains to limit the preloaded domain surface area.
- Consider excluding non-critical domains like test/staging environments from preloading.
- Plan for contingencies and long lead times in case preloaded domains need removal.
What are the Alternative Options to Chrome’s HSTS Preload List
If unable to preload a domain into Chrome’s hardcoded list, alternatives like these provide similar security:
- The Firefox HSTS Preload List works similarly but only for Firefox browsers.
- Per-user HSTS rules can be added manually in the browser or via enterprise policies.
- Consider allowing the first HTTP connection but redirecting to HTTPS and enabling HSTS for subsequent visits.
Final Words
Adding important domains to Chrome’s HSTS Preload List provides robust protection against SSL stripping attacks and reduces initial connection instability. However, list modifications are challenging, so sites must decide if the trade-offs are warranted. Thorough testing and planning are essential when preloading to avoid disrupted functionality.
Frequently Asked Questions
What should I do before preloading my domain?
Before preloading:
- Ensure your site works fully on HTTPS.
- Enable a long HSTS max-age header across subdomains.
- Fix any HTTP endpoints.
Test preload readiness and functionality impact.
Does HSTS preloading work for subdomains?
Yes, Chrome’s HSTS preload list applies to subdomains as well if the HSTS header uses include Sub-Domains. Be sure to preload and test the apex domain and critical subdomains.
How long does it take to get preloaded?
It takes anywhere from months to years after submission before preloading activates in Chrome. The list updates are only alongside the major version of Chrome releases.
Can I remove my site from the HSTS preload list?
Removal is difficult after preloading. You have to request Chromium developers to manually delist, which can also take months. So, preloading requires a long-term HTTPS commitment.
What happens if I sell a preloaded domain?
The new owner will inherit the preloaded HSTS status. They must continue supporting HTTPS on the domain or go through a complex removal process.
Does HSTS preloading work on all browsers?
No, Chrome’s preload list is only for Chromium-based browsers. Firefox has its preload list. For broader support, use Cloudflare’s Always Use HTTPS option.
Can I override HSTS for a preloaded site?
No, users cannot bypass the HSTS restrictions enforced by Chrome’s preload list. The browser will block HTTP access and forbid overriding certificate errors.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
![What is Certificate Revocation List [CRL]?](https://sslinsights.com/wp-content/uploads/2024/01/certificate-revocation-list-crl.png)
