hstspreload.org Open in urlscan Pro
2001:4860:4802:38::15  Public Scan

URL: https://hstspreload.org/
Submission: On May 02 via api from LU — Scanned from DE

Form analysis 2 forms found in the DOM

<form id="domain-form" class="">
  <h2><label for="domain"> Enter a domain: </label></h2>
  <input id="domain" name="domain" type="text" placeholder="example.com" autocorrect="off" autocapitalize="off" spellcheck="false">
  <br>
  <input id="check" type="submit" value="Check HSTS preload status and eligibility">
</form>

<form id="submit-form" class="hidden">
  <hr>
  <h2>Submit</h2>
  <div id="checkboxes">
    <label>
      <input type="checkbox" id="checkbox-owner"><span>I am the site owner of <code><span class="domain-text">example.com</span></code> or have their permission to preload HSTS.</span>
    </label>
    <span id="oops"> (If this is not the case, <code><span class="domain-text">example.com</span></code> may be sending the HSTS <code>preload</code> directive by accident. Please
      <a id="oops-mailto" href="mailto:hstspreload@chromium.org">contact hstspreload@chromium.org</a> to let us know.) </span>
    <br><br>
    <label>
      <input type="checkbox" id="checkbox-subdomains"><span>I understand that preloading <code><span class="domain-text">example.com</span></code> through this form will prevent <strong>all subdomains and nested subdomains</strong> from being
        accessed without a valid HTTPS certificate: <span class="subdomain-example"><code>*.<span class="domain-text">example.com</span></code></span>
        <span class="subdomain-example"><code>*.*.<span class="domain-text">example.com</span></code></span>
        <span class="subdomain-example"><code>...</code></span>
      </span></label>
  </div>
  <br>
  <input id="submit" type="submit" disabled="" value="Submit to the HSTS preload list">
  <div id="submit-success" class="submit-feedback hidden">
    <hr>
    <h2>Success</h2>
    <p><code class="domain-text">example.com</code> is now pending inclusion in the HSTS preload list! </p>
    <p>Please make sure that <code class="domain-text">example.com</code> <strong>continues</strong> to satisfy all preload requirements, or it will be removed. Please revisit this site over the next few weeks to check on the status of your domain.
    </p>
    <p>Also consider scanning for TLS issues <a id="ssl-labs-link" href="https://www.ssllabs.com/ssltest/analyze.html">using SSL Labs</a>.</p>
  </div>
  <div id="submit-failure" class="submit-feedback hidden">
    <hr>
    <h2>Failure</h2> An error occurred. Please start over.
  </div>
</form>

Text Content

On GitHub


ENTER A DOMAIN:


Submitting entries to the HSTS preload list via this site requires JavaScript.







--------------------------------------------------------------------------------


SUBMIT

I am the site owner of example.com or have their permission to preload HSTS. (If
this is not the case, example.com may be sending the HSTS preload directive by
accident. Please contact hstspreload@chromium.org to let us know.)

I understand that preloading example.com through this form will prevent all
subdomains and nested subdomains from being accessed without a valid HTTPS
certificate: *.example.com *.*.example.com ...


--------------------------------------------------------------------------------


SUCCESS

example.com is now pending inclusion in the HSTS preload list!

Please make sure that example.com continues to satisfy all preload requirements,
or it will be removed. Please revisit this site over the next few weeks to check
on the status of your domain.

Also consider scanning for TLS issues using SSL Labs.

--------------------------------------------------------------------------------


FAILURE

An error occurred. Please start over.


INFORMATION

This form is used to submit domains for inclusion in Chrome's HTTP Strict
Transport Security (HSTS) preload list. This is a list of sites that are
hardcoded into Chrome as being HTTPS only.

Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have
HSTS preload lists based on the Chrome list. (See the HSTS compatibility
matrix.)


SUBMISSION REQUIREMENTS

If a site sends the preload directive in an HSTS header, it is considered to be
requesting inclusion in the preload list and may be submitted via the form on
this site.

In order to be accepted to the HSTS preload list through this form, your site
must satisfy the following set of requirements:

 1. Serve a valid certificate.
 2. Redirect from HTTP to HTTPS on the same host, if you are listening on port
    80.
 3. Serve all subdomains over HTTPS.
    * In particular, you must support HTTPS for the www subdomain if a DNS
      record for that subdomain exists.
    * Note: HSTS preloading applies to all subdomains, including internal
      subdomains that are not publicly accessible.
 4. Serve an HSTS header on the base domain for HTTPS requests:
    * The max-age must be at least 31536000 seconds (1 year).
    * The includeSubDomains directive must be specified.
    * The preload directive must be specified.
    * If you are serving an additional redirect from your HTTPS site, that
      redirect must still have the HSTS header (rather than the page it
      redirects to).

For more details on HSTS, please see RFC 6797. Here is an example of a valid
HSTS header:

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

You can check the status of your request by entering the domain name again in
the form above, or consult the current Chrome preload list by visiting
chrome://net-internals/#hsts in your browser. Note that new entries are
hardcoded into the Chrome source code and can take several months before they
reach the stable version.


CONTINUED REQUIREMENTS

You must make sure your site continues to satisfy the submission requirements at
all times. Note that removing the preload directive from your header will make
your site immediately eligible for the removal form, and that sites may be
removed automatically in the future for failing to keep up the requirements.

In particular, the requirements above apply to all domains submitted through
hstspreload.org on or after October 11, 2017 (i.e. preloaded after Chrome 63)

The same requirements apply to earlier domains submitted on or after February
29, 2016 (i.e. preloaded after Chrome 50), except that the required max-age for
those domains is only 10886400 seconds.


DEPLOYMENT RECOMMENDATIONS

If your site is committed to HTTPS and you want to preload HSTS, we suggest the
following steps:

 1. Examine all subdomains (and nested subdomains) of your site and make sure
    that they work properly over HTTPS.
    * Note: This also includes internal subdomains that are not publicly
      accessible.
 2. Add the Strict-Transport-Security header to all HTTPS responses and ramp up
    the max-age in stages, using the following header values:
    * 5 minutes:
      max-age=300; includeSubDomains
    * 1 week:
      max-age=604800; includeSubDomains
    * 1 month:
      max-age=2592000; includeSubDomains
    During each stage, check for broken pages and monitor your site's metrics
    (e.g. traffic, revenue). Fix any problems that come up and then wait the
    full max-age of the stage before you move on. For example, wait a month in
    the last stage.
 3. Once you're confident that there will be no more issues, increase the
    max-age to 2 years and submit your site to the preload list:
    * 2 years, requesting to be preloaded:
      max-age=63072000; includeSubDomains; preload

If you have a group of employees or users who can beta test the deployment,
consider trying the first few ramp-up stages on those users. Then make sure to
go through all stages for all users, starting over from the beginning.

Consult the Mozilla Web Security guidelines and the Google Web Fundamentals
pages on security for more concrete advice about HTTPS deployment.


PRELOADING SHOULD BE OPT-IN

If you maintain a project that provides HTTPS configuration advice or provides
an option to enable HSTS, do not include the preload directive by default. We
get regular emails from site operators who tried out HSTS this way, only to find
themselves on the preload list by the time they find they need to remove HSTS to
access certain subdomains. Removal tends to be slow and painful for those sites.

Projects that support or advise about HSTS and HSTS preloading should ensure
that site operators understand the long-term consequences of preloading before
they turn it on for a given domain. They should also be informed that they need
to meet additional requirements and submit their site to hstspreload.org to
ensure that it is successfully preloaded (i.e. to get the full protection of the
intended configuration).


REMOVAL

Be aware that inclusion in the preload list cannot easily be undone. Domains can
be removed, but it takes months for a change to reach users with a Chrome update
and we cannot make guarantees about other browsers. Don't request inclusion
unless you're sure that you can support HTTPS for your entire site and all its
subdomains in the long term.

However, we will generally honor requests to be removed from Chrome's preload
list if you find that you have a subdomain that you cannot serve over HTTPS for
strong technical or cost reasons. To request removal, please visit the removal
form.


TLD PRELOADING

Owners of gTLDs, ccTLDs, or any other public suffix domains are welcome to
preload HSTS across all their registerable domains. This ensures robust security
for the whole TLD, and is much simpler than preloading each individual domain.
Please contact us if you're interested, or would like to learn more.


CONTACT

Want to remove your domain? Please visit the removal form.

Else, if you have questions or requests that are not covered by this site, email
us here using an appropriate subject line and one of the preload list
maintainers will be in contact soon.