What is HSTS, and why does a scan flag it?

The HTTP Strict-Transport-Security response header (HSTS) tells browsers that a host should only be reached over HTTPS, and that future attempts over HTTP should be upgraded to HTTPS automatically. If every page and subdomain of your site already works over HTTPS, turn it on with a short max-age first and raise it once nothing breaks.

What is HSTS and why does it matter?

HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that a web application turns on with a special response header. Once a supported browser receives this header, it stops sending anything over HTTP to that domain and sends everything over HTTPS instead. It also prevents HTTPS click through prompts on browsers.

Every time the browser receives the header, it updates the host's HSTS expiration time. The specification was published at the end of 2012 as RFC 6797 by the IETF.

Check whether any of these apply to your site:

• A user bookmarks or types the http:// address of a site and is exposed to a man-in-the-middle attacker. HSTS automatically redirects HTTP requests to HTTPS for the target domain.
• A web application meant to be purely HTTPS accidentally contains HTTP links or serves content over HTTP.
• A man-in-the-middle attacker tries to intercept traffic with an invalid certificate and hopes the user will accept it. HSTS does not allow a user to override the invalid certificate message.

Here is how that looks on Atlas, our example app. If a browser remembers atlas.example as an HSTS host and the header used includeSubDomains, opening http://login.atlas.example still goes over HTTPS.

For the full directive list, read MDN's Strict-Transport-Security reference.

Which HSTS value should I send?

Pick the row that matches your site today. Read the OWASP HSTS cheat sheet before you send one.

When using preload, the max-age directive must be at least 31536000 (1 year), and the includeSubDomains directive must be present. OWASP describes the preload list as maintained by Chrome and used by Firefox and Safari.

How do I check?

Run this from a terminal to read the headers Atlas sends over HTTPS:

curl -sI https://atlas.example

Look for a line that starts with Strict-Transport-Security, and note its max-age and whether it has includeSubDomains or preload. Then read the plain HTTP answer, which on Atlas is a redirect to HTTPS:

curl -sI http://atlas.example

The host must send the Strict-Transport-Security header over HTTPS only, not insecure HTTP. The redirect must not include the Strict-Transport-Security header, since the request used insecure HTTP. Each subdomain host should include Strict-Transport-Security headers in its responses. Repeat the first command for every subdomain you run.

Lockpick checks your site from the outside, the way a stranger or an attacker would find it. It reads the homepage and the files it loads, security headers and TLS, and public DNS, certificate and subdomain records, in at most 10 requests. If a scan flags HSTS, open the HSTS policy check and HSTS reach across subdomains check pages.

Check your site

How do I fix it?

1. Confirm every page, file and subdomain of your site loads over HTTPS. Write down any subdomain that only works over plain HTTP.
2. Send the first-rollout value from the table on every HTTPS response. Click through the site and its subdomains while it is live.
3. Raise max-age once nothing breaks, using the long value from the table:

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

1. Add preload only if you are sure you will never go back to HTTP. The preload flag indicates the site owner's consent to have their domain preloaded, and the site owner still needs to submit the domain to the list.
2. Check again after you deploy, with the curl commands above or a new scan.

Add this response header to every HTTPS response the app serves, including pages, API routes and static files.
Strict-Transport-Security: max-age=86400; includeSubDomains
Do not add it to plain HTTP responses or to the HTTP to HTTPS redirect. Before changing anything, list every subdomain the app uses and tell me if any of them only works over HTTP. If one does, remove includeSubDomains and tell me which subdomain it was. Do not add preload. Show me where you set the header and how I can confirm it with curl -sI.

Set this response header on every HTTPS response from the app and its hosting config, including pages, API routes and static files.
Strict-Transport-Security: max-age=86400; includeSubDomains
Do not send it on plain HTTP responses or on the HTTP to HTTPS redirect. List every subdomain the app uses first, and stop and ask me if any of them only works over HTTP. Do not add preload. Tell me which file you changed.

The app already sends a short Strict-Transport-Security header and nothing has broken. Change it on every HTTPS response to the line below, keeping it off plain HTTP responses and the HTTP to HTTPS redirect.
Strict-Transport-Security: max-age=63072000; includeSubDomains
Do not add preload unless I ask for it. Show me the change and the curl -sI command to confirm it.

What a check cannot tell you

Don't read a missing Strict-Transport-Security header as proof that your site was attacked or exploited. Treat it as a setting to change.

If the header goes missing from a host that sent it before, the previous header remains in effect until its expiration time. Test in a fresh browser profile as well as the one you use every day.

Lockpick never signs in to your site and never looks at anything behind a login. If your signed-in pages come from a different server or route, check their headers yourself with curl. Anything a scan couldn't check is marked as not checked, never as passed.

A Lockpick report is not a certificate and not a full penetration test. It covers what that scan could see on that day. Read How Lockpick checks a site before you rely on a report.