HSTS improves security by requiring all browser connections to use HTTPS rather than HTTP.
HSTS delivers the following benefits:
- Mitigates the risk of sensitive data leaking out unencrypted.
- Improves data integrity. HTTPS mitigates the risk of man-in-the-middle attacks because your website’s encryption certificate is validated by the end user’s browser.
How it works
HSTS instructs the browser to use HTTPS when making requests to your website. The browser remembers this instruction for an amount of time that you set, so the next time a user visits your website, their browser will use HTTPS.
HSTS works through the use of the Strict-Transport-Security response header. Once a browser receives this header, it prevents sending any communications over HTTP to the specified domain and sends it all over HTTPS instead. Insecure HTTP links are converted to secure HTTPS links. For example, http://example.com/some/page/ is converted to https://example.com/some/page/ before accessing the server. If the security of the connection can’t be ensured (for example, the server’s TLS certificate isn’t trusted), the user sees an error message and can’t access the site.
Features and options
| Field | What it does | Sub-options |
|---|---|---|
| Enable | Turns the HTTP Strict Transport Security (HSTS) behavior on or off. | |
| Max age | Specify the maximum length of time that all browsers connect to your site using HTTPS. Changing the value of Max age affects new connections only. Browsers that connected prior to the update continue to use the Max age in effect at the time. |
|
| Include all subdomains | Specifies whether all subdomains are required to use HTTPS. This includes any intranet or delegated hosts in the domain that connect through Akamai. | |
| Preload | Adds the domain to the browser’s preload list that’s hardcoded into Google Chrome, and other browsers that have preload lists based on the Chrome list. You still need to declare the domain at hstspreload.org. The presence of your domain in the preload list means that a browser will connect using HTTPS from the very first attempt, protecting against bootstrap man-in-the-middle attacks. If your domain isn’t in the preload list, the initial connection from a browser will use HTTP, after which your site will send the HSTS header to the browser, requiring it to connect using HTTPS.
Note: The Preload list is updated and distributed when new builds of the browsers are released. It can take months for your domain to be included in the list and propagated to large numbers of users. If you want the domain to be included in the preload list, familiarize yourself with the configuration requirements listed on the submission page at hstspreload.org. Your configuration must meet all of the requirements to be included in the preload list. |
|
| Redirect all HTTP requests to HTTPS | When enabled, redirect all HTTP requests to HTTPS. If you do not configure your site to redirect HTTP requests, all connections using HTTP will be ignored. |
|
Implementation
When you implement HSTS, there’s a risk that the system will deny access to users when HSTS isn’t configured correctly. For example, your domain may have absolute links or subdomains that will become inaccessible after you configure the domain to require the use of HTTPS. Because of this risk, and the difficulty in reversing the requirement to force connections to use HTTPS, you can configure two rules in the domain’s property that will let you turn HSTS on and off using queries in the requests to the domain.
To implement HSTS for a domain, you need to
- Verify that the domain is configured to support HSTS.
- Configure rules and behaviors that will allow you to turn on and turn off HSTS by sending requests from your browser to the domain.
- Test HSTS in a staging network before implementing it in production.