Web security — HTTPS, HSTS, redirects, subdomain takeover
The Web security category checks how the site is served, not just whether a certificate exists. It confirms HTTPS is enforced (not merely available), that HSTS is set, that redirects settle cleanly without loops, and it hunts for subdomains pointing at deprovisioned services that an attacker could claim. A site that's down or won't resolve fails outright — a hollow site can't coast to an A.
The HTTPS enforcement check — labeled “HTTPS enforced” — is the anchor of this category and one of the more heavily weighted checks overall. It passes when HTTPS is reachable and a plain HTTP request 3xx-redirects to HTTPS. It warns when HTTPS is available but not enforced (HTTP still serves content directly). It fails — definitively — when the site is HTTP-only, isn't responding at all, or the domain doesn't resolve.
HSTS (“HSTS”) reads the Strict-Transport-Security header on the real origin, following the apex↔www redirect to wherever the site actually lives. It passes when the header is present with a max-age of at least 120 days. It warns on a weak or zero max-age, or when a WAF challenge page gets in the way. It fails when the header is absent on a page that returns a 2xx, or when HTTPS is unreachable.
The redirect check (“Redirects”) follows the redirect chain from the domain. It passes when the chain ends on a 2xx response with no loop and within the hop cap. It warns when there are more than four hops, the chain is truncated, or it settles on a non-2xx page. It fails when there's a redirect loop or the chain ends in a 4xx or 5xx error.
The subdomain-takeover check (“Subdomain takeover”) enumerates a domain's subdomains via Certificate Transparency logs (crt.sh, capped at 40), then fingerprints each one's response against a database of deprovisioned-service signatures — GitHub Pages, S3, Heroku and the like. A high-severity match fails; an edge or low-confidence match warns; no matches passes. If CT returns no subdomains it's marked not-applicable, and if the CT lookup fails it's an error. It's always hedged as “may be vulnerable”, and the probing is SSRF-safe — it never reaches out to internal IP addresses.
A site that's down or won't resolve is a definitive HTTPS-enforced fail. If the domain doesn't respond or doesn't resolve, this check fails outright rather than being skipped — so a hollow or dead site can't coast to a high grade on the strength of its other records.
The subdomain-takeover result is deliberately hedged. It reports a subdomain that “may be vulnerable” because a takeover can only be confirmed by actually claiming the dangling resource. Treat a finding as a strong lead to investigate — a subdomain pointing at a service nobody owns anymore — not a proven compromise.
Frequently asked questions
What's the difference between HTTPS being available and enforced?
Available means the site answers on HTTPS. Enforced means a plain HTTP request is redirected to HTTPS so visitors can't stay on the insecure version. The check passes only when HTTPS is reachable and HTTP 3xx-redirects to it; HTTPS available but not enforced only warns.
My site is down — why did that fail a security check?
A site that isn't responding, is HTTP-only, or whose domain doesn't resolve is a definitive fail on the HTTPS-enforced check. It's failed rather than skipped on purpose, so a dead or hollow site can't quietly keep a high grade.
How does subdomain-takeover detection work?
It enumerates subdomains from Certificate Transparency logs (crt.sh, capped at 40) and fingerprints each response against a database of deprovisioned-service signatures (GitHub Pages, S3, Heroku, etc.). A high-severity match fails, an edge case warns, no match passes. Results are hedged as “may be vulnerable”, and the probing never touches internal IPs.
What does the HSTS check need to pass?
A Strict-Transport-Security header present on the real origin with a max-age of at least 120 days. A weak or zero max-age (or a WAF challenge blocking the read) warns; an absent header on a 2xx page, or unreachable HTTPS, fails.