Free Tools

HSTS Checker

Check whether your domain has HSTS enabled, valid, and properly configured with a strong max-age and includeSubDomains.

Why HSTS matters

HTTP Strict Transport Security (HSTS) tells browsers to always connect to your domain over HTTPS — even if the user types  http:// or clicks an unencrypted link. Without it, any connection that starts as plain HTTP can be intercepted and downgraded by a man-in-the-middle attacker before the browser gets a chance to redirect.

Once a browser has seen a valid HSTS header it remembers the policy for  max-age seconds. Every subsequent request skips the initial HTTP round-trip entirely, eliminating an entire class of SSL-stripping attacks.

The  includeSubDomains directive extends this protection to every subdomain. Without it a subdomain running plain HTTP — even a forgotten staging environment — can be used as an entry point to steal cookies or redirect users.

Common HSTS issues

HSTS header missing

Your server never sends a  Strict-Transport-Security header. All traffic is vulnerable to SSL stripping until the user has visited the site at least once over a secure connection.

Fix: add Strict-Transport-Security: max-age=31536000; includeSubDomains to your server config.

Invalid header — no max-age

A header is sent but it does not contain a parseable  max-age directive. Browsers will ignore the policy entirely, providing no protection.

Fix: ensure max-age=<seconds> is present and contains a numeric value.

max-age too short

A  max-age below 15,552,000 seconds (180 days) is considered weak. Browsers forget the policy quickly, leaving short windows where downgrade attacks are possible.

Fix: set max-age to at least 15552000, ideally 31536000 (one year).

includeSubDomains missing

The main domain is protected but subdomains are not. An attacker can exploit any subdomain still accessible over HTTP — including forgotten staging or internal tooling — to bypass HTTPS enforcement on the parent domain.

Fix: add includeSubDomains once all subdomains are confirmed HTTPS-ready.

Monitor HSTS changes over time

A point-in-time check tells you where you stand today. But HSTS headers change — deployments silently drop the directive, max-age values get shortened by misconfigured CDNs, and includeSubDomains disappears after infrastructure changes.

DomainRisk.io tracks HSTS across every scan as part of a broader SSL and header analysis. Any regression — a header going missing, a max-age being reduced, includeSubDomains being removed — triggers an alert so you catch the change before attackers do.

Frequently asked questions

What is HSTS?
HTTP Strict Transport Security (HSTS) is a web security policy delivered via the Strict-Transport-Security HTTP response header. It instructs browsers to only communicate with your domain over HTTPS for a defined period (max-age), eliminating the initial HTTP round-trip that SSL-stripping attacks exploit.
What is a good max-age value for HSTS?
The recommended minimum is 15,552,000 seconds (180 days). Most security guidelines recommend 31,536,000 seconds (one year). The HSTS preload list requires at least 31,536,000 seconds. Short values such as 300 or 3,600 seconds offer negligible protection since the browser forgets the policy almost immediately.
What does includeSubDomains do?
The includeSubDomains directive extends the HSTS policy to every subdomain of your domain. Without it, subdomains remain vulnerable to downgrade attacks even if the apex domain is protected. You should only enable it once you have confirmed that all subdomains are accessible over valid HTTPS.
What is HSTS preloading?
The preload directive signals your intent to be included in the browser HSTS preload list — a hardcoded list of domains that browsers enforce HTTPS on before any connection is made, even on the very first visit. Inclusion requires a max-age of at least 31,536,000s, the includeSubDomains directive, and submission to hstspreload.org. Preloading is very difficult to undo, so only enable it when every subdomain is permanently HTTPS-ready.
Does HSTS protect against all man-in-the-middle attacks?
HSTS prevents SSL-stripping and protocol downgrade attacks by forcing the browser to use HTTPS. It does not protect against attacks on the TLS layer itself (expired certificates, weak cipher suites, invalid chains) or against DNS-level attacks such as DNS hijacking. A comprehensive security posture requires HSTS alongside valid TLS certificates, DNSSEC, and strong email authentication.
Can I enable HSTS if some of my subdomains still use plain HTTP?
You can set HSTS on the apex domain without includeSubDomains. This protects the main domain but leaves subdomains exposed. To use includeSubDomains — which is the recommended configuration — every subdomain must serve a valid HTTPS response. Audit your subdomains first, migrate them to HTTPS, then add includeSubDomains.
How often should I check my HSTS configuration?
A point-in-time check only tells you the current state. HSTS headers can silently regress after deployments, CDN configuration changes, or infrastructure migrations. Continuous monitoring that alerts you when max-age drops, includeSubDomains disappears, or the header goes missing entirely is the reliable approach.
Continuous monitoring

Start continuous domain security monitoring

HSTS, DNS, SSL, WHOIS, email authentication and subdomains — monitored continuously with change alerts and an explainable risk score.

Start Free TrialSee all features

Scan limit reached

You've used your 5 free scans for this minute.

Create a free account for unlimited scans, continuous monitoring, full findings and remediation guidance.

Create a free account