What is HTTP Strict Transport Security?

HSTS is one of the measures used to reduce the possibility of various passive and active attacks, such as man-in-the-middle (MITM). In addition, it serves to provide a more secure connection between clients and servers. Read more below!

What is HSTS?

HTTP Strict Transport Security (HSTS) is a web security policy that ensures that browsers always connect to websites via HTTPS. Part of its purpose is to remove the need to redirect users from HTTP to HTTPS website versions or secure any such redirects.

This is achieved via the HSTS header sent by the server back to the client at the beginning of the connection. This header informs the browser that after the first visit, which HSTS does not cover, it should interact with the website only via HTTPS.

The Strict Transport Security header also prevents users from ignoring browser warnings about invalid or insecure SSL/TLS certificates. 

How does HSTS work?

When users visit a website with the HSTS policy enabled, they will usually first make an HTTP request to the server. Then, depending on the setup, they will either arrive at an HTTP version or, in a more secure scenario, be redirected by the server to the HTTPS version of the website via a 301, 302, or 307 redirects. The client will then reconnect to the HTTPS version of the website.

At this stage, the server will send the HTTP Strict-Transport-Security response header over the HTTPS connection. In addition, the header will include different parameters about connecting to the website subsequently. 

In its most secure and recommended form, the header will instruct the browser to remember the HSTS policy for a certain amount of time, also known as the max-age directive. Typically that period will be at least a year, though specified in seconds (see example below). It will also intrust the browser to consider the policy as applying to all of the website’s subdomains and preload the website. This is what the header looks like in this form:

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

From that moment on, no HTTP connections to the website are allowed. If a user attempts to load a page or other content via HTTP, the browser is required to try an HTTPS request instead. If this is not possible, the resource will not be accessible, and the connection attempt will be terminated. Moreover, if the server’s certificate is not trusted, the policy must also prevent users from accessing the website or application.

The purpose of the preload parameter is to avoid creating the vulnerability associated with visiting the website for the first time. Websites that comply with several requirements can submit a request to be included in a browser’s preload list (see Chrome’s HSTS Preload list). When included in the list, a browser will load the HTTPS version of a website already at the first attempt of accessing by a user. 

While there are limitations to this approach, since hardly all websites can be included in preload lists, it is one way of addressing the above vulnerability.

HSTS Security Assessment

Security Assessment Increase TLS Key Size


How secure is HSTS?

The HSTS header helps prevent several different cyber attacks. This includes SSL stripping – a form of man-in-the-middle attack (MITM), session hijacking (also known as cookie hijacking or sidejacking) attempts, and various downgrade attacks. This is particularly the case if a website is added to preload lists.

However, certain limitations and vulnerabilities still exist if the preload option is unavailable. For example, the first request to a website is still vulnerable to an attack if an insecure protocol is used, such as plain HTTP, even with a redirect request to HTTPS. There are few workarounds to this issue. One possible way of addressing this is to use DNS records that declare HSTS Policy and access these records safely through DNSSEC.

The HSTS header, regardless of its setup, cannot prevent the use of fraudulent domains that trick users into visiting them. This can be achieved via DNS spoofing, another type of MITM, or by attackers using domain names closely resembling a website’s domain name.

Finally, HSTS cannot prevent attacks against the TLS protocol itself. Attacks such as BEAST and CRIME target vulnerabilities inherent in specific versions or implementations of TLS and are not covered by the policy.

Prevention Guide for SSL/TLS Vulnerabilities

Prevention Guide

Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.


How to enable HSTS?

Below you can find examples of how to enable HSTS on different platforms. 

It’s important to note that when deploying, HSTS policy should be declared at the base domain (sometimes called the root domain, though there is a difference). In our case, that would be instead of 

To cover subdomains, the includeSubDomains directive should be utilized. But for this to work, all subdomains associated with the base domain must naturally also support HTTPS. 

Use the following guides to set the correct header enabling HSTS.

Let’s Encrypt

With Let’s Encrypt, it is straightforward to enable HSTS. When creating a new certificate, just ad the –HSTS flag. If your certificates are already generated by Let’s Encrypt, just run the same command and choose “Attempt to reinstall this existing certificate” as the first option. This will reuse your certificate and enable HSTS stapling.

certbot run -d [DOMAIN] --staple-ocsp --hsts


On Nginx you need to update your SSL configuration which is usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/ (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS) to include the correct header with the add_header directives:

server {
        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";
        listen   443;
        root /usr/share/nginx/www;
        index index.html index.htm;
        ssl on;
        ssl_certificate /etc/nginx/ssl/;
        ssl_certificate_key /etc/nginx/ssl/;
        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;

Strict Transport Security Apache

On Apache you need to update your SSL configuration to include the correct Header directives. Add this to the virtual host configuration in /etc/apache2/sites-enabled/domain.conf or /etc/httpd/sites-enabled/domain.conf:

<IfModule mod_ssl.c>
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
    <VirtualHost *:443>
            Header always set Strict-Transport-Security "max-age=31536000"
            ServerAdmin webmaster@localhost
            DocumentRoot /var/www
            SSLEngine on
            SSLCertificateFile /etc/apache2/ssl/
            SSLCertificateKeyFile /etc/apache2/ssl/
            SSLCACertificateFile /etc/ssl/ca-certs.pem
            SSLUseStapling on


What does HSTS mean?

HSTS stands for HTTP Strict Transport Security. This web security policy guarantees that clients only access the HTTPS version of a website instead of the HTTP one. It serves as protection against man-in-the-middle attacks such as SSL stripping, downgrade attacks, and more.

Does HSTS provide complete security?

No, HSTS has its limitations. For example, if a website is not part of a browser’s preload list, users are still vulnerable to an attack the first time they visit the website. HSTS also cannot protect against SSL/TLS protocol attacks. That said, HSTS provides very high security and significantly limits the possibility of attacks against direct HTTP connections.

Get a quick security report for your website for free now

We are analyzing
Scanning target
Scan status: In progress
Scan target:
Date: 30/11/2023
Crashtest Security Suite will be checking for:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Complete your scan request
Please fill in your details receive the
quick security audit by email.
Security specialist is analyzing your scan report.
То verify your identity please provide your phone/mobile:
Thank you.
We have received your request.
As soon as your security audit is ready, we will notify you.