Does your site tell browsers to always use HTTPS?
The HSTS check looks for a Strict-Transport-Security header with a positive lifetime on your pages. With it, browsers use HTTPS on every later visit, even when someone types a plain http address.
What does this check look at?
It looks at whether your pages tell browsers to keep using HTTPS on later visits, with a Strict-Transport-Security header that has a positive lifetime. MDN describes the header as telling browsers that the host should only be accessed using HTTPS.
MDN also notes one weakness of HSTS, which is that it does not take effect until the browser has made at least one secure connection to the host.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | The sampled pages send the header with a positive lifetime. | Nothing, unless the reach check says your other addresses are left out. |
| Attention | No usable header was seen. | Add the header after confirming the whole site works over HTTPS. |
A missing policy weakens later visits but does not prove anyone has intercepted traffic. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Someone on the visitor's network |
| The protection that should stop it | A transport setting on the sampled responses |
| What is reached | Traffic between visitors and the site |
| What follows | A hardening gap; no interception was attempted |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A04:2025 Cryptographic Failures |
| CWE | CWE-319 |
| ASVS | v5.0.0-3.4.1 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
Add the header where your host or framework sets response headers. Start with a short lifetime, then raise it once nothing breaks.
Add a Strict-Transport-Security response header to every page of my site. First confirm that every page and asset already loads over HTTPS. Start with max-age=300, deploy, check the site, then raise it to max-age=31536000. Do not add includeSubDomains or preload yet; I will review my other subdomains first. Set it in the hosting or framework config (for example next.config headers, vercel.json, netlify.toml or a _headers file) and show me the change.Raising the lifetime in steps keeps a mistake from locking visitors out for a year.
How to check
Say Atlas, our example app at atlas.example, sends no Strict-Transport-Security header. A Pulse scan marks the check for attention, and after the fix the next scan shows a pass.
The free quick check covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. Pulse or Deep explains the difference.
Questions people ask
Is a missing HSTS header a vulnerability?
It is a hardening gap. It leaves the first plain HTTP request on a new network open to tampering, but it does not prove anyone has intercepted traffic.
Should I add preload straight away?
No. Getting off the preload list is slow, so add it only after every subdomain has worked over HTTPS for a while.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Strict-Transport-Security header MDN Web Docs, read on October 7, 2026