Does your HSTS rule cover your other subdomains too?
The HSTS reach check looks at whether a long-lived Strict-Transport-Security rule also covers the other addresses on your domain, through the includeSubDomains setting. Without it, those addresses can still be reached over plain HTTP on a first visit.
What does this check look at?
It looks at whether a long-lived HSTS policy also covers the other addresses on your domain. MDN says the includeSubDomains directive instructs the browser to apply a domain's HSTS policy to its subdomains as well.
Your other addresses come from public certificate logs, which list every name a certificate was issued for. When the scan reads a www address, the rule that reaches your other subdomains is the one your main domain sends.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | The long-lived rule includes subdomains. | Nothing. |
| Attention | The rule lasts a year or more but leaves subdomains out. | Check each subdomain works over HTTPS, then add includeSubDomains. |
| Not tested | No long-lived rule was seen, so reach was not judged. | Fix the HSTS check first. |
The other addresses are never contacted, so it cannot say whether each one serves HTTPS today. 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
Extending the rule is safe only once every subdomain serves HTTPS, so the prompt starts with that inventory.
List every subdomain of my domain that is still in use (check my DNS records and hosting projects). For each one, confirm it loads over HTTPS with a valid certificate. If all of them do, add includeSubDomains to the Strict-Transport-Security header on my main domain, keeping the current max-age. If any subdomain cannot serve HTTPS, stop and tell me which one instead of changing the header.How to check
Say Atlas, our example app at atlas.example, sends a one year HSTS rule without includeSubDomains, and certificate logs list a help address. The check names that address as left out, and nothing is ever sent to it.
Run a Pulse scan from your Lockpick account to see it for your site. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
Can adding includeSubDomains break anything?
Yes. Any subdomain without working HTTPS becomes unreachable in browsers that saw the rule, so check them all first.
Why did the scan not contact my other subdomains?
It only reads the site you approved. Your other addresses come from public certificate logs, and checking them is your call.
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