23 September 2022

What is HSTS, HTTP Strict Transport Security?

HTTP Strict Transport Security is a web security policy mechanism that allows websites to declare themselves accessible only through secure connections.


HTTP Strict Transport Security (HSTS) is a web security policy mechanism that allows websites to declare themselves accessible only over secure connections. This helps protect websites and users from protocol downgrades and cookie hijacking attacks.

HTTP Strict Transport Security (HSTS) has a fascinating history dating back to 2008. It all started with a research paper called “Forced HTTPS: Protecting High-Security Web Sites from Network Attacks“, written by Collin Jackson and Adam Barth. This groundbreaking work laid the groundwork for what would become HSTS, outlining the fundamental idea of ​​forcing website connections to use HTTPS to improve security.


Then, on September 18, 2009, a significant evolution took place when PayPal, along with Jackson and Barth, released a revised version of the protocol outline contained in the original document. This updated document, which is available online, was a step forward in defining what would become HSTS.

The next crucial phase in the history of HSTS occurred on December 18, 2009, when the latest “community version” of the then-named “STS” specification was released. This release incorporated changes based on feedback received from the Internet security community, further refining the guidelines for using HSTS.

Finally, the formal specification of HSTS (RFC 6797) was published on November 19, 2012, after being approved on October 2, 2012 by the Internet Engineering Steering Group (IESG), a body composed of the chair of the Internet Engineering Task Force (IETF) and by the various area directors. This approval marked the formalization of HSTS as the security standard for website connections, confirming its key role in protecting users from various network attacks.

Why was HSTS introduced?

The HTTP protocol (Hypertext Transfer Protocol) is a communication protocol widely used for the transmission of information on the Internet. This protocol relies on various transport systems, the most common of which is the Transmission Control Protocol (TCP). TCP is the fundamental pillar of the transport system and ensures the reliable delivery of data between interconnected systems.

However, TCP has one significant shortcoming: it offers no protection of data integrity, information confidentiality, or secure host identification. In other words, information transmitted over TCP is vulnerable to unauthorized interception, data alteration, and false identification.

This lack of security has motivated the creation of additional protocols to improve data security during transmission. Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), were born with just this goal. These protocols provide a layer of encryption that acts as a shield between application protocols and TCP. The combined use of HTTP and SSL/TLS gives rise to what we commonly refer to as HTTPS, or secure HTTP.

User agents, like web browsers, use various local security policies to decide how to interact with a host. This decision is based on a number of factors, including negotiation between the server and the user agent, user preferences, and the communication method used (HTTP or HTTPS).

However, in some circumstances, users may choose to continue interacting with a website even when they are unable to establish a secure connection. This can happen when a TLS certificate's chain of trust is not validated, when the certificate has expired, or when the TLS host's domain name is displayed incorrectly in the certificate. This practice is known as “click-through insecurity”.

Although this possibility may seem convenient for the user, it introduces potential security risks. Users who decide to continue using a website without a secure HTTPS connection become vulnerable to various types of cyber attacks. Prominent among these are man-in-the-middle (MITM) attacks, in which an attacker intercepts and potentially tampers with communication between two parties, downgrade attacks, which force a connection to use a less secure protocol, and session hijacking, in which an attacker takes control of a user's session.


HTTP Strict Transport Security (HSTS) is a security mechanism that allows websites to state that they can only be accessed over a secure connection. This means that a website can prevent users from connecting to it through any insecure connections, such as those based on the HTTP protocol. This measure effectively protects users from a well-known security vulnerability called SSL-stripping.

SSL stripping is a type of downgrade attack, a particularly insidious form of cryptographic attack on a computer system or, as in this case, a communication protocol. The downgrade attack forces the system or protocol to give up its encrypted connection (HTTPS) and instead adopt an older unencrypted connection (HTTP), which is generally kept in place for backwards compatibility with older systems.

SSL stripping was first presented by Moxie Marlinspike in his talk at the 2009 BlackHat conference, titled “New Tricks for Defeating SSL in Practice”. This attack is implemented as part of a man-in-the-middle attack, where web traffic is intercepted and diverted from the secure HTTPS version of the website to an unencrypted HTTP version.

A major factor that allows this type of attack to continue to succeed is that many websites do not use TLS/SSL certificates. As a result, it is impossible to determine (without prior knowledge) whether a website's lack of HTTPS is due to an SSL stripping attack or because the site does not have a TLS certificate.

A particularly alarming aspect of this attack is that there are no signals or warnings that can warn the user during the downgrade process. This makes the attack difficult to detect even for the most observant and security-aware user.

Marlinspike's creation of a tool to fully automate this type of attack makes SSL stripping a serious cybersecurity risk. The threat posed by these attacks highlights the importance of taking proper security measures, such as using HSTS, to ensure the integrity and security of online communications.

Session Hijacking - Session Hijacking

Session hijacking, also known as session hijacking or cookie hijacking, is a type of security vulnerability that can be exploited through click-through insecurity, a behavior that allows users to continue interacting with a website despite the lack of a secure HTTPS connection.

In a session hijacking attack, an attacker exploits a valid session between a computer and a server to gain unauthorized access to information or services. This type of attack is particularly relevant to web developers, since cookies, small text files saved on the user's device, are used to maintain session state on many websites.

If a website doesn't mark its cookies as secure, instructing user agents, such as web browsers, to send cookies only over an HTTPS connection, they can easily be intercepted and stolen by an attacker. In fact, unsecured cookies are sent to the host regardless of the security of the transport channel used, which makes them vulnerable to man-in-the-middle attacks. These attacks occur when an attacker manages to intercept and potentially manipulate communication between two parties without either party being aware of it.

Once an attacker has gained access to the cookies, he can impersonate the original user on a legitimate website, using the session credentials saved in the cookie to access the site's protected resources as if he were the legitimate user. This type of attack can have serious consequences, including unauthorized access to your personal, financial, or sensitive information.

It is important to note that in order to prevent session hijacking, it is essential that websites use secure HTTPS connections and mark their cookies as secure so that they are only sent over encrypted connections. Additionally, users should be aware of the risks associated with insecure click-throughs and should avoid accepting insecure connections whenever possible.

How does HSTS work?

HTTP Strict Transport Security (HSTS) is a security protocol that allows web servers to declare that all interactions between a web browser or other user programs must occur over HTTPS connections, which offer secure encryption, instead of unsecured HTTP connections .

A server can implement an HSTS policy by providing a specific response header over an HTTPS connection. This header, called Strict-Transport-Security, specifies a period of time during which the interpreter, such as a web browser, must access the service exclusively via HTTPS requests. It is important to note that HSTS headers sent over insecure HTTP responses are ignored to avoid the possibility of malicious manipulation.

How HSTS works is relatively simple. The first time a user accesses a site via HTTPS and the site returns the Strict-Transport-Security header, the browser logs this information. Then, future attempts to load the site via HTTP will automatically be redirected to HTTPS, thus ensuring a secure connection.

Once the amount of time specified by the Strict-Transport-Security header has elapsed, the next attempt to load the site via HTTP will proceed as usual, instead of automatically being redirected to HTTPS. However, whenever the Strict-Transport-Security header is provided to the user agent, it will update the validity period for that site. As a result, sites may continue to send these headers to prevent HSTS policy expiration.

In case it is necessary to disable HSTS, web servers can set the maximum age value to zero on an HTTPS connection. This will immediately expire the HSTS header, thus allowing access via HTTP requests.

An example of how HSTS works would be a server sending a header requesting that all future requests for the next year use HTTPS only. This can be accomplished via the Strict-Transport-Security header: max-age=31536000.

When a web application sends an HSTS policy to user agents, the compliant user agents automatically change all insecure connections to secure connections. For example, a link like http://example.com/ would be transformed into https://example.com before reaching the server. Also, if a secure connection cannot be established, for example because the server does not have a valid certificate, the user agent will drop the connection and not allow the user to access the website.

The most important aspect of HSTS is that it prevents insecure click-through by not allowing the user to use the insecure connection. This is to protect users from various types of cyber attacks, such as man-in-the-middle attacks, downgrade attacks, and session hijackings.

What is an example of a situation involving HSTS?

Let's consider a practical example that illustrates the importance and effectiveness of HTTP Strict Transport Security (HSTS). Let's say a member of your team decides to use a free Wi-Fi hotspot in a coffee shop to surf the web. During her browsing session, she decides to log into your organization's payroll system to check her salary details.

WiFi Bar

Unfortunately, the Wi-Fi access point you connected to is not secure. It's run by a hacker who set up his laptop to intercept HTTP requests in transit. When your employee tries to access your payroll system, the hacker intercepts the original HTTP request and redirects your employee to a bogus website, a perfect copy of your payroll system. This leads to the exposure of your employees' personally identifiable information (PII), creating a significant privacy and security concern.

However, if your payroll system uses HSTS and your employee has previously visited the site using an HTTPS connection, their browser will remember to use only HTTPS connections for that site in the future. This means that no matter how much the hacker tries to redirect your employee's traffic to a fake website over an insecure HTTP connection, the employee's browser will insist on using HTTPS only.

In this way, the use of HSTS effectively protects your employee and your payroll system from potential man-in-the-middle attacks. Demonstrating how crucial it is for organizations to ensure that their websites properly implement the HSTS protocol, in order to maintain the security and privacy of their users and their data.

What are the limitations of HSTS?

HTTP Strict Transport Security (HSTS) is a powerful tool for securing web connections, but it also has some fundamental limitations.

The first is that a user who is unable to establish a secure HTTPS connection will not be able to access the website that implements HSTS. This can create accessibility issues in circumstances where HTTPS connections are problematic or unavailable.

Also, the HSTS policy communication is via an HTTP response header, which means that the user must first visit the website to find out that it uses HSTS. This implies that the first request to the website, if made through an insecure protocol such as HTTP, remains vulnerable to active attacks. The same applies to the first claim after the expiry of the period specified in the HSTS "max-age" guideline. This period is usually set to last for several days or months, depending on the site's specific needs and user behavior.

To mitigate this problem, many browsers support "preloading" HSTS policies. This means they maintain a list of websites known to use HSTS and automatically use an HTTPS connection for the first request to these sites. However, this approach doesn't scale to the entire web. There have been discussions about using DNS records and DNSSEC to declare and ensure the use of HSTS, which may offer a more general solution.

Another limitation of HSTS is its ineffectiveness against certain types of attacks. It doesn't protect against, for example, typosquatting attacks, DNS-based attacks, or man-in-the-middle attacks using fake domains that aren't included in the browser's HSTS prefetch list.

Finally, since HSTS depends on the TLS protocol, its security is related to the robustness of TLS. If there are vulnerabilities in TLS, HSTS will be indirectly affected.

For a more detailed and technical discussion of these and other aspects of HSTS, please consult Request for Comments (RFC) 6797.

HSTS preloads

HSTS “Preloading” is a method used to improve website security and overcome one of the main limitations of HSTS – the fact that the user must have previously visited the site before the HSTS policy is met. HSTS preloading solves this problem by including the website in a predefined list of sites using HSTS, distributed with the browser. In this way, when a user visits the site for the first time, the browser already knows that he must use HTTPS, thus avoiding the "first contact" problem.

hstspreload.org is a service that allows website owners to request inclusion of their site in the HSTS preload list distributed with major browsers. To be included in this list, a website must meet a number of specified criteria, including sending a proper HSTS header with a "max-age" value of at least 31536000 seconds (approximately one year), and inclusion of the “includeSubDomains” and “preload” directive.

To configure an NGINX web server to send the correct headers and meet these criteria, you need to add the following configuration within the “server” block in your NGINX configuration file:

server { # ... other server configurations ... add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; # ... other server configurations ... }

Once this configuration is implemented, it is possible to request the inclusion of the site (in our example, example.it) in the HSTS preload list through hstspreload.org. Just enter your site's domain in the input field provided and follow the instructions provided. The site will then be checked to make sure it meets all the necessary criteria, and if all is well, it will be added to the list.

The HSTS preloading process does not happen in real time, but rather in conjunction with each new release of Google Chrome. This is because the default list of sites using HSTS is included in every version of the Google Chrome browser. Once a website has applied for and met the requirements for inclusion through hstspreload.org, the site is added to the list and this change is included in the next version of Google Chrome.


However, it is important to note that there may be a significant waiting period before the inclusion takes effect. Google releases new versions of Chrome every six weeks or so, but there could be an additional delay before the change is incorporated into the browser. This is because there may be many pending inclusion requests and the process of reviewing and adding to the list takes time.

Overall, one should expect it to take at least two to three months for a site to be included in Chrome's default list after the initial request. However, once included in the list, all website visitors using an updated version of Chrome will benefit from the HSTS policy from their first contact with the site.

HSTS preloading and improvement of TTFB performance and values.

Preloading HSTS (HTTP Strict Transport Security) not only improves overall website security, but can also help improve overall site performance and reduce Time to First Byte (TTFB). TTFB is a metric that measures the time that elapses from the moment a client (for example, a web browser) sends an HTTP request until it receives the first byte of the response from the web server. Reducing TTFB can greatly improve the overall speed of loading a web page and the user experience.

With HSTS enabled and configured for preloading, the user's browser knows in advance that it should only communicate with the website over a secure HTTPS connection, therefore eliminating the need for an HTTP redirect to HTTPS. This redirection can introduce additional latencies that increase TTFB.

Without HSTS, the user's browser may initially attempt to establish an insecure HTTP connection, which the server then redirects to an HTTPS connection. This redirect takes time and slows down page loading.

With HSTS preloading, this redirection is avoided, which can lead to a reduction in TTFB, making the website faster and more responsive. This is an especially significant benefit for high-performance websites, where even minor improvements in TTFB can have a dramatic impact on user experience and overall site speed.

What are the best practices for deploying HSTS?

HTTP Strict Transport Security (HSTS) deployment best practices are designed to optimize the security of your site and ensure that all visitors to your site benefit from the protection afforded by HSTS. Here we will focus on how to successfully deploy HSTS if your site is HTTPS bound and you intend to preload HSTS. The following steps outline the process:

  1. Make sure you provide a valid certificate: A valid SSL/TLS certificate is essential for establishing a secure HTTPS connection. This implies that the certificate must be issued by a recognized certificate authority (CA) and that your site name must match the name specified in the certificate.
  2. Redirect from HTTP to HTTPS on the same host, if you're listening on port 80: This step is critical to ensuring all connections to your site are secure. All HTTP requests should be redirected to HTTPS on the same host.
  3. Serve all subdomains over HTTPS: Make sure all subdomains on your site use HTTPS to ensure secure connections throughout your domain.
  4. Support HTTPS for www subdomain if a DNS record exists for that subdomain: If your site has a DNS record for a www subdomain, it must support HTTPS.
  5. Needs an HSTS header in the base domain for HTTPS requests: The header must specify a maximum age of at least 31536000 seconds (1 year), must include the includeSubDomains directive and the preload directive.
  6. If you're serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header.

To achieve an optimal level of security, it is recommended to follow these steps:

  • Start by examining all of your site's subdomains and nested subdomains to ensure they are working over HTTPS.
  • Next, enable HSTS for all HTTPS responses and progressively increase the maximum age. During each stage, closely monitor your site metrics, troubleshoot any issues that arise, and wait for the stage's maximum age before proceeding. You can follow this progression for maximum header age: 5 minutes, 1 week, 1 month.
  • Once you're sure there's no problem, increase the maximum age to 2 years and submit your site to the HSTS prefetch list with the prefetch directive.

Finally, you can submit your website for inclusion in the HSTS preload list via hstspreload.org. This site is maintained by the Chromium project team and provides a way for websites to be included in the HSTS preload list distributed with Chrome and other Chromium-based browsers

Which browsers support HSTS?

HSTS (HTTP Strict Transport Security) enjoys broad support among major browsers, confirming its vital role in increasing the security of internet connections.

Chromium and Google Chrome were among the first browsers to support HSTS, starting with version This marked a major step forward in implementing advanced security measures to protect internet users from potential attacks.

Firefox started supporting HSTS starting with version 4. But with the introduction of Firefox 17, Mozilla went one step further by integrating a list of websites that support HSTS, further improving user security.

Opera, starting with version 12, started supporting HSTS, recognizing the importance of providing a secure connection to its users.

Safari started supporting HSTS starting with OS X Mavericks, version 10.9. This has provided an extra layer of security for Safari users, helping them browse the internet more securely.

Internet Explorer 11 on Windows 8.1 and Windows 7 started supporting HSTS when update KB 3058515 was installed. This allowed its users to benefit from the protections offered by HSTS.

Microsoft Edge and Internet Explorer 11 on Windows 10 support HSTS, further strengthening the security of these browsers.

Finally, the BlackBerry 10 Browser and WebView also support HSTS, starting with BlackBerry OS 10.3.3. This confirms the importance of HSTS not only for desktops, but also for mobile devices.


Briefly summarizing, HTTP Strict Transport Security (HSTS) is an important security mechanism that helps protect websites and their users from various types of attacks, including man-in-the-middle attacks. It works by forcing browsers to use secure HTTPS connections with websites that implement the HSTS policy.

However, HSTS has some limitations. It requires the user to visit the website first to learn its HSTS policy, which can leave the first request exposed to potential attacks. This is where HSTS preloading comes into play. HSTS preloading allows websites to be included in a list of HSTS sites that is distributed with browsers, thus eliminating the need for the user to first visit the site to find out its HSTS policy.

Setting up HSTS preloading requires a few steps, including setting specific headers and submitting your site to the HSTS preloading list. While it can be a bit complex to set up, it offers an extra layer of security that is worth considering.

In addition, HSTS preloading can also improve website performance by reducing the Time to First Byte (TTFB), which can lead to a better user experience.

Finally, HSTS has broad browser compatibility, including Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, Safari, and the BlackBerry 10 Browser.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top