Web Application Security

HTTP Strict Transport Security

What is it and why should I care?

HTTP Strict Transport Security (HSTS) is a new(ish) technology that allows an application to force browsers to use only SSL/TLS (HTTPS, not HTTP) when they visit that application. This occurs when the application sets an HSTS-specific HTTP response header. Browsers that support HSTS recognize the response header and only communicate with that application over HTTPS for the specified time.

Here are the basic steps of the flow:

Step 1: A user visits the application, either over HTTP or HTTPS. For most users this will be HTTP, because they often forget (or don’t know) to type in https://

Step 2: The application renders the response, including the HSTS response header, which specifies that the site should be loaded over HTTPS for only the next 90 days

Step 3: The supporting browser will not issue a non-SSL request to that application for the next 90 days

What should I do about it?

Set the header! This is another no-brainer. There are no backwards-compatibility issues, and setting the header only enhances your security posture. By adding the header, you give your users greater security with very little effort on your part. Here’s a quick example of what setting the header might look like if you happen to code in Java:

HttpServletResponse …;

response.setHeader(“Strict-Transport-Security”, “max-age=7776000; includeSubdomains”);

The snippet above sets the amount of time that the browser should use only HTTPS when accessing the application (or any subdomains) to the next 90 days.


The max-age attribute is required, and it sets the number of seconds that only HTTPS should be used. This can be set to whatever length of time you want. Setting this to “0” tells the browser to delete the existing policy and, therefore, not to require HTTPS.


The includeSubdomains attribute is optional. It does not take a value; its presence signifies that any sub-domains should abide by the same HSTS policy.

Expiration Reset

The time length (90 days in our example above) should be reset (overwritten) by the supporting browser every time the HSTS response header is received. This means that if you set the length to 90 days, and visitors never go more than 90 days without entering your site, they’ll always be visiting over HTTPS because the 90 days re-sets every time they visit. Just keep in mind that if you change the setting, all browsers that access your site (post-change) will get the update. If you set the expiration for 90 days today, and then for 10 days tomorrow, the browsers will discard the 90-day setting and replaces it with the new one of 10 days.

Click-Through Insecurity

The HSTS spec also recommends (though the current spec doesn’t seem to require it) that the browser not send any data to the server if the channel is insecure for any reason (certificate issues, domain issues, etc.). Apparently, current browser implementers are following this recommendation because it is the most secure option. This means that the warning pop-ups that users often see over HTTPS connections (mixed content, expired cert) no longer appear and, instead, users simply see an error.

Pre-Loaded HSTS Lists

If you want to have even more assurance that your site is visited only over HTTPS, you can request that your site be pre-loaded into a list of HSTS sites. This means that the browser will require users to go that site over HTTPS on their very first visit!

HSTS is a simple and effective control that lets an application provide users with further protection by forcing them over HTTPS. If your site is (or it at least should be) HTTPS-only, then implementing HSTS can provide you and your users with enhanced assurance.









  • http://securitylearn.wordpress.com satish b

    Very good article.

    How does the browser remember the expiration time (90 days)? Does it store any where on the disk?

  • Santhosh

    @Satish B: This is a response header added at the time you visit the website. So, My guess is that if should be in browser memory or cache

  • Santhosh

    Hi John,

    I understand that the HSTS provides enhanced assurance for users. But how is this differs from redirecting the user to HTTPS if they try to load HTTP of the particular site.

  • http://www.jtmelton.com johnmelton

    @Satish B: It’s up to the browser as to how to store this data. It’d be stored somewhere on disk, but it would be browser-dependent and proprietary.

    @Santhosh: There are probably several reasons, but two that come to mind quickly are click through insecurity as I mentioned above and misconfiguration.

    The click through insecurity concept removes the opportunity for users to say “ignore your security warnings – I know what I’m doing”. It just doesn’t allow the user to visit the site that has issues.

    The misconfiguration concept recognizes that while we might try with the best of intentions, we still make silly mistakes. SSL is not always configured properly. HSTS ensures that users are protected when visiting the site and that the connection is always done securely

  • Dan T

    The article is missing a subtle nuance. Step 2 only works when the connection is https. This means Step 1 has two variations – when the site is accessed via http, the usual handling is to redirect (301) to the https site, when the site is accessed via https, everything proceeds as described. This is important because the initial access over http is a weakness – and the pre-loaded list helps to overcome it. But, other than that, nice concise article! Thx!