The fix, in one snippet
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now reads the Strict-Transport-Security header from the HTTPS response to / and parses its directives: max-age (seconds), includeSubDomains and preload. The check fails when the header is absent, when max-age is below 15552000 (180 days), or when it is max-age=0, which instructs browsers to forget a previously stored policy. A header seen only on the plain-HTTP response is ignored, exactly as RFC 6797 section 8.1 tells browsers to ignore it, so it does not count. Multiple HSTS headers with conflicting values are reported because browsers process only the first. includeSubDomains being absent is noted rather than failed: it is the right setting for most sites but only once every subdomain serves HTTPS. Preload eligibility is assessed separately in hsts-preload-ready.
Why it matters
A redirect protects the current request; HSTS turns it into a policy the browser enforces on its own. After one visit, the browser rewrites every http://example.com URL to HTTPS internally before any packet leaves the machine, and it refuses to let the user click through a certificate warning for that host. That closes the SSL-stripping window that the redirect check describes, and it also stops a quieter attack: an on-path adversary who injects an <img src="http://example.com/"> into any other HTTP page to make the victim's browser send your cookies in the clear. A short max-age undermines this, because the policy expires between visits for anyone who returns less often than the window. The HSTS guide walks through the header, subdomain scope and the preload list.
How to fix it
Send the header on every HTTPS response, not only the homepage. Start with a short max-age such as 300 while you confirm that every subdomain works over HTTPS, then raise it. The value below (two years, subdomains included, preload token present) is what the preload list requires:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
nginx (the always keyword makes nginx add it to error responses too):
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
Apache:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Express with Helmet:
app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true, preload: true }));
On Cloudflare, enable HSTS under SSL/TLS > Edge Certificates; the dashboard asks you to acknowledge that a wrong setting can lock users out, which is the right caution. Do not add includeSubDomains if any subdomain (an internal tool, a mail host with a web interface) is still HTTP-only, because the policy applies to them all.
Where this fits
Strict-Transport-Security (HSTS) is check 8 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Certificate signature algorithm (medium), where a certificate in the chain is signed with SHA-1, MD5 or another broken hash. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Strict-Transport-Security (HSTS) closes one route in. Immediately below it: Weak cipher suites accepted, where the server is willing to negotiate legacy cipher suites such as RC4, 3DES, export-grade, NULL or anonymous suites, or offers TLS 1.2 suites without forward secrecy; TLS 1.3 support, where the server negotiates TLS 1.2 at best and does not offer TLS 1.3; HSTS preload eligibility, where the domain does not yet meet the requirements for the browser HSTS preload list.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Strict-Transport-Security (HSTS) (medium severity)
Scanner check id: hsts
The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.