Security
Force the secure version of your site
Your site is served over HTTPS but never tells the browser to insist on it, so a visitor returning over an insecure connection is not protected.
Why it matters
Browsers display a padlock for HTTPS, and visitors have learned to look for it. Without this header, the very first request a returning visitor makes can still go over plain HTTP, where it can be intercepted and altered. The header also prevents a class of attacks that silently downgrades a secure connection.
How you would notice it
- The padlock protects one page but not another on the same site.
- Security scanners flag a missing HSTS header.
- If you ran a security scan for a client or insurer, this is almost always one of its findings.
What to do
We publish this header on our own domain. Two notes from doing it, both of which changed what we put in the file.
Stage 1
- Confirm the whole site works over HTTPS first. Turn HSTS on while part of the site is still HTTP and you will lock visitors out of those pages.
Check your contact page and any subdomains too. This header applies to every page on the domain.
https://www.example.com/Stage 2
- Add the header in your web server or host configuration, starting with a short max-age.
This is the safe first move, and it already earns part of the credit: a short max-age is a real policy in force and scores 8 of the 15 points this check is worth. Only an explicit clear, max-age=0, earns nothing at all. Raise the value once the site has run normally.
Why we left includeSubDomains off
This header can be set to cover every subdomain you own, and most tutorials present that as the finished version. We publish it without that part on purpose. A product we run lives at a subdomain of the same domain, and the directive would have forced it to HTTPS only the moment the header arrived, with no cheap way back: browsers keep the rule until the timer you set runs out. It is not required for a good score either. Turn it on only when every subdomain is already HTTPS and none is being introduced later.
Source: Production multi-subdomain routing review on noblemarketglobal.com
# nginx
add_header Strict-Transport-Security "max-age=300" always;Stage 3
- Once the site has run normally for a day, raise max-age to a long value.
15552000 seconds is six months and is the minimum most scanners accept as durable. Use 31536000 for one year if the site is fully HTTPS across every subdomain.
# nginx
add_header Strict-Transport-Security "max-age=15552000" always;Stage 4
- Add includeSubDomains only if every subdomain you own already works over HTTPS, and only once you are sure none is being introduced later.
Do not add this to a domain you are still building on. Every subdomain is covered the moment the header arrives, so an HTTP-only staging address becomes unreachable immediately, and browsers keep it that way until your max-age runs out. It is not required for a good score, so skip it if you are unsure.
What a short timer actually scores
The safe way to start is a short timer, and it is worth knowing what that costs while it runs. The scoring model treats any positive timer as a real policy in force and gives it part of the credit: a short one scores 8 of the 15 points this check is worth, and only an explicit clear, a timer set to zero, earns nothing at all. So a partial score during a staged rollout is not a fault in the report. It is the report telling you the policy is real but not yet durable. Raise the timer once the site has run normally and the remaining points follow.
Source: Siege Test v2.2 scoring engine calibration harness audit
# nginx
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Stage 5
- Run the site normally for a day and check that nothing is broken before you raise the value.
How to check it worked
Confirm it worked
Check your response headers again and confirm you see strict-transport-security with a max-age of at least 15552000. While you are still running the short version, the report will look different rather than unchanged: a short max-age earns part of the credit, and what remains is a recommendation narrowed to one instruction asking you to raise the value. The check reads the length of the policy, and a max-age of 0 is the one value that counts as no policy at all. Re-run the Siege Test after you raise max-age and confirm the recommendation is gone.