HTTP Strict Transport Security (HSTS)

Description

HTTP Strict Transport Security (HSTS) is a security policy mechanism that helps protect websites against protocol downgrade attacks and cookie hijacking. When a server includes an HSTS header (Strict-Transport-Security) in its response, it instructs compliant browsers to only connect to that site using HTTPS for a specified period of time. As a result, any subsequent visits—whether initiated by the user, a script, or a redirect—will occur over HTTPS, effectively preventing users from mistakenly making insecure HTTP connections.

HSTS improves overall transport security by discouraging the use of vulnerable plain-text connections. It also helps protect against attacks such as SSL stripping, where an attacker might intercept communications and downgrade the connection to HTTP without the user noticing.

Examples

Basic HSTS Header

A simple example of the Strict-Transport-Security header might look like this:

Strict-Transport-Security: max-age=31536000

Here, 31536000 seconds equals one year. This instructs the browser to remember the requirement to only use HTTPS for the next 365 days. If a user or script attempts to connect via HTTP, the browser automatically upgrades the connection to HTTPS, bypassing an insecure request.

Preload Directive

Some sites add the includeSubDomains and preload directives:

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

• includeSubDomains applies the HSTS policy to all subdomains, ensuring they also enforce secure connections.
• preload is used by browsers that maintain a preloaded list of HSTS sites. Once a domain is accepted into the preload list, browsers will force HTTPS even for first-time visits, eliminating the possibility of a first unsecure request.

Remediation

1. Serve All Traffic Over HTTPS
   • Ensure you have a valid TLS certificate configured for your domain.
   • Redirect all HTTP requests to the HTTPS version of the site before or as you implement HSTS.
2. Set Appropriate HSTS Header
   • Decide on a sufficient max-age value (commonly at least 31536000 seconds or 1 year).
   • Consider using includeSubDomains to cover subdomains.
   • Apply preload only if you are confident all subdomains use HTTPS and you intend to submit your domain to browser preload lists.
3. Incremental Rollout
   • If you are unsure about the readiness of subdomains, start with a smaller max-age and without includeSubDomains.
   • Gradually increase max-age and then add includeSubDomains as you gain confidence that every part of your infrastructure is TLS-secure.