1. About this Study

A browser respecting the Strict-Transport-Security header (defined in RFC 6797) will access the website sending this header only via a secure connection for the following requests. This prevents e.g. session cookies to be leaked by being sent through insecure connections.

The data shown in the following charts is based on weekly scanns of more than 200M domains. All IP addresses of a given domain are scanned individually. While computing the here shown data these IP scanns are merged based on the domain (FQDN), so that a domain with multiple IP addresses only appears once.

All of the charts can be viewed in absolute values as amount of domains, or in relative values as percentage of domains with sts enabled (or percentage of scanned domains in case of the adoption chart). Additionally the data set can be selected with "IPv4" showing only data for domains that were scanned via IPv4, "IPv6" respectively for domains scanned via IPv6 and "Merged" showing data for both of the previous scans merged by the domain.

This study is part of the bachelor thesis "Long Term Analysis of the HTTP Strict Transport Security Header".

2. Adoption

This chart shows how many domains include a valid HSTS header in their HTTPS response, as well as domains that include their subdomains in the strict transport security policy and domains that have preloading enabled. For further details about these configuration options, see section 3.

3. Configuration

The HSTS header can be configured with the three directives max-age, includeSubDomains and preload (with the later one not being defined in the official RFC, but being used by most browsers to generate their preloading lists).

3.1 max-age

The max-age directive is required for the header to be valid and can have any positive integer value. This value specifies the duration in seconds for which the strict transport security policy should be active. The spread of the value used for this directive can be seen in the following chart.

Legend details

The following intervals show exactly how the max-age values map to the categories shown in the chart.

Name Interval
>1 year
]370d; infinity[
1 year
]360d; 370d]
<1 year
]190d; 360d]
6 months
]180d; 190d]
<6 months
]7d  ; 180d]
≤1 week
]1d  ; 7d]
≤1 day
]1h  ; 1d]
test
]0s  ; 1h]
off
[0s  ; 0s]

3.2 includeSubDomains and preload

The other two directives do not have any values, but can either be set or not. The includeSubDomains directive extends the strict transport security policy to any subdomains of the domain that the HSTS header was sent initially. By setting preload directive the owner of a website allows its domain to be included in preload lists that come with most browsers.

4. Anomalies

This section displays anomalies that were found while analyzing the scan data.

4.1 Inconsistencies

Here shown are inconsistencies in the configuration and existence of the HSTS header between scans of domains that are served via multiple IP addresses.

The following chart shows inconsistencies across multiple IP address of the same version for a single domain. An inconsistency in the configuration of the HSTS header requires any of the directives to have differing values, or being set when the website is served on one IP address, but not being set when the website is served on another IP address. A domain is inconsistent in the existence of the HSTS header if it is being sent on one IP, but not on another IP of the same domain. The total inconsistencies statistic shows the domains with any of the above inconsistencies.

Inconsistencies between different IP versions are found by defining a set of quad tuples for each IP version. Every quad tuple contains whether a valid HSTS header was set, the value of the max-age directive and whether the includeSubDomains and preload directives were set. If such a quad tuple is found in the set for one IP version, but not for the other, the domain being served on those IP addresses is considered inconsistent between IP versions.

4.2 Parse Errors

While parsing the HSTS header parse errors can occur in case the header does not apply to RFC 6797. However a header that causes a parse error might still be valid if it is syntactically correct and all of the required directives are given.

Top 10 parse errors

These are the ten most common parse errors that occurred in the most recent scann.

# Occurences Error