Let us describe how exactly HSTS Policy can be enabled in cPanel.

Opening .htaccess file for editing

First of all, we need to open the .htacess file for editing. It can be done by following the steps below:

• While logged in to the cPanel account, locate Files section and click on File Manager button.

  

• Click Settings at the top-right side of the screen:
  

  

  Click the Document Root for: radio button in the pop-up window and select the domain name from the drop-down list for which HSTS needs to be enabled. Make sure that Show Hidden Files (dotfiles) checkbox is enabled. Click Save.
  

  

• Click on "public_html" folder in the directory tree on the left side of the newly opened window. Locate the .htaccess file in the main window, select it by single-clicking and click on the Edit button in the upper navigation bar.
  

  
  Confirm the Edit option in the following pop-up window as well.

  

• Once the necessary records are added to the .htaccess file, press Save button in the upper right corner for the changes to take instant effect.

  

You can see on the screenshot above how the HSTS header generally should look like. A template of a syntactically correct record valid for implementing in the .htaccess with all the possible directives included is given below:

Header set Strict-Transport-Security: "max-age=31536000 ; includeSubDomains ;" env=HTTPS

The meaning of each directive and how exactly it should be used will be explained in the next part of this article.

HSTS implementation models

Let us review different use cases and specific HSTS header variants, corresponding to them.

The construction of an HSTS header field consists of its name, i.e. Strict-Transport-Security, and a set of directives, which are either optional or required, as stipulated in their definitions.

NOTE: All directives must appear only once in an STS header field.

The required "max-age" directive specifies the number of seconds after the reception of the STS header field during which a web browser examines the host from which the message was received, as a Known HSTS Host. There are different approaches to setting the “max-age” directive value, depending on its implementation purpose: it could be either a "constant value into the future" or a "fixed point in time". Both of the approaches are outlined in section 11.2 of RFC-6797.

The HSTS header field below declares that the HSTS Policy is to remain in effect for one year (there are approximately 31536000 seconds in a year), and the policy applies only to the main domain name:

Strict-Transport-Security: max-age=31536000

If a web administrator wishes to enable HSTS Policy for the main domain name and all of its subdomains as well, an “includeSubDomains” directive should be added to the HSTS header:

Strict-Transport-Security: max-age=15768000; includeSubDomains

NOTE: The application of “includeSubDomains” directive must be carefully thought through in order to avoid possible connection failure. The example scenarios of subdomains deployment and how the HSTS header should be set in a particular case, are described in section 11.4 of RFC-6797.

The HSTS header field below indicates that the web browser must delete the entire HSTS Policy associated with the HSTS Host that sent the header field:

Strict-Transport-Security: max-age=0

Thus, if one, for some reason, decides to disable HSTS Policy for a particular domain name, it is enough to change the “max-age” directive value to “0”. The web browser after receiving the updated HSTS header removes the domain name from the storage of Known HSTS Hosts.

The HSTS header field below has exactly the same effect as the one above because the “includeSubDomains” directive’s presence in the HSTS header field is ignored when max-age is zero:

Strict-Transport-Security: max-age=0; includeSubDomains

HSTS Preloaded list

One more point to implement in terms of HSTS, if you are pursuing the goal of an absolute security is including an HSTS Host to preload list. The very first request of a particular domain name will remain vulnerable, since a web browser at that exact moment “does not know” that the requested website is using HSTS Policy. The following situation takes place due to the fact that the Strict-Transport-Security header is sent from the server to the client in an HTTP response via a secure HTTPS only and cannot be received before the secure session is established.

In order to remove this minor issue, the HSTS Preloaded List has been created and implemented to Chrome and then to the rest of HSTS-conformant web-browsers. The list of domain names, that are known as those that have HSTS Policy enabled and will be keeping it enabled constantly, is incorporated to the web browsers at the stage of their development and is called HSTS Preloaded List. Thus, a user will be able to connect to the website with such a domain name in a secure fashion from scratch, with HSTS enabled.

Basically, any domain name can be included to the HSTS Preloaded List, if all requirements are met and a website administrator commits to maintain an HTTPS server for the given website and not to permit any interruptions, caused by the certificate or server configuration issues.

Before making a decision whether to add a particular domain name to the list, one should take into account that its exclusion from the aforementioned list is a rather complicated procedure, as the list can be only updated with the next web browser version release. And since HSTS Policy implies that the website cannot be served via plain HTTP with HSTS enabled, such a website could stay inaccessible for its visitors for a considerable period of time.

NOTE: The STS header of the domain name, included to the Preloaded list, must contain an additional “preload” directive, e.g.: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.