1The Vulnerability: The "HTTPS-only" Illusion
The moment a domain gets an SSL certificate, most organizations consider their HTTPS story closed. The padlock appears. The audit checkbox is ticked. The reality is different: the certificate protects the connectiononce it is established in HTTPS.It does nothing to guarantee that the connectionstartsin HTTPS.
The vault with an open door
An SSL certificate is a vault-grade safe. The combination is uncrackable, the walls are impenetrable. But if the door is open by default and you only lock it after the customer walks in, an attacker standing in the doorway can intercept them before the vault closes. HSTS is the mechanism thatlocks the door before the customer even arrives.
The First-Contact Problem
When a user typesexample.comin their browser — without thehttps://prefix — the browser sends anHTTP request.The server then redirects to HTTPS. This redirect is the attack surface. An attacker positioned between the client and the server can intercept that initial HTTP request and prevent the upgrade from ever happening.
Step-by-step attack flow when HSTS is not configured
User enters example.com (without https://)
No https:// prefix means the first packet leaves the machine unencrypted. This is unavoidable without HSTS.
Attacker intercepts the initial HTTP request (MITM)
Via rogue Wi-Fi access point, ARP poisoning on a local network, or ISP-level interception.
Attacker relays to origin over HTTPS
The server responds normally - it sees a valid HTTPS connection from what appears to be a standard client.
Attacker strips HTTPS and keeps victim on HTTP
The user sees the site load correctly over HTTP. The padlock never appears. No browser warning is triggered.
Session stays exposed to interception/tampering
Credentials, session tokens, form data - everything the user submits is fully readable by the attacker.
A certificate does not prevent SSL Stripping.
The attack bypasses the certificate entirely — it never reaches the encrypted channel. The user sees no browser warning. The server logs show a normal session. The attack is invisible to both ends and leaves no forensic trace in standard access logs.
2What is HSTS?
HTTP Strict Transport Security (HSTS), standardized inRFC 6797(2012), is a server-sent response header that instructs a browser to interact with the domain exclusively over HTTPS — for a configurable duration. Once received, the browser enforces this policy locally, without any network round-trip.
What the browser hears
"For the next31,536,000 seconds,do not initiate any HTTP connection to this domain. If anything — a link, a redirect, a resource, a cookie — tries to use HTTP, upgrade it to HTTPSbefore it leaves the browser.Do not ask me whether this is still valid. Do it unconditionally."
The 307 Internal Redirect
Traditional HTTP→HTTPS redirects are301 or 302 responses from the server.HSTS replaces them with a307 Internal Redirect— generated entirely within the browser, before any packet is sent. There is no first HTTP request. There is no first contact. The SSL Stripping attack has no opportunity to intercept anything because the browser never emits an HTTP request to begin with.
Without HSTS
- âœ-Browser sends HTTP GET to server
- âœ-Server returns 301 redirect to HTTPS
- âœ-Browser follows redirect — second request
- âœ-TLS handshake finally occurs
- âœ-Attacker can intercept step 1
With HSTS
- ✓Browser checks local HSTS store
- ✓307 Internal Redirect generated in-browser
- ✓Browser sends HTTPS request directly
- ✓TLS handshake occurs immediately
- ✓No HTTP packet ever leaves the machine
3Anatomy of the HSTS Header
A fully configured HSTS header — the industry standard for production environments — looks like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload| Directive | Purpose & Recommendation |
|---|---|
max-age=31536000 | Tells the browser how long (in seconds) to enforce the HSTS policy. 31,536,000 is exactly one year - the industry standard for production. Start with a lower value (e.g. 3600) during testing; increase to one year once the policy is confirmed stable. The timer resets on every HTTPS visit. |
includeSubDomains | Extends the policy to every subdomain. Critical for infrastructure security - without it, an attacker can still strip TLS on sub.example.com even if example.com is protected. Caution: activating this directive when a subdomain lacks a valid certificate makes that subdomain instantly inaccessible. |
preload | Opts the domain into browser preload lists - hardcoded HSTS databases shipped with Chrome, Firefox, Safari and Edge. Even a first-ever visit is protected. Requires max-age >= 31536000, includeSubDomains, and submission to hstspreload.org. |
The preload list: the highest level of HSTS protection
Preloading means your domain is baked into the browser binary. No user needs to visit your site once before being protected — HTTPS is enforced from the very first connection, on every device in the world. Domains are submitted athstspreload.org. Removal from the list takes months to propagate — do not preload unless you are fully committed to HTTPS on all subdomains indefinitely.
4The Implementation Gap
HSTS is technically simple to deploy — a single response header. Yet a significant portion of production domains either do not have it configured, have it set with an insufficient max-age, or have it withoutincludeSubDomains. The gap is not technical — it is organizational.
The Blocking Risk
Activating includeSubDomains when a subdomain - dev, staging, internal tools, legacy admin panel - has no TLS certificate makes that subdomain instantly inaccessible. No warning. No fallback.
The Admin Fear Factor
Most admins know their subdomain landscape is incomplete. They hesitate to enforce includeSubDomains because they cannot confidently enumerate every subdomain. The policy stays off indefinitely.
The Monitoring Gap
HSTS configuration drifts. A max-age set to 300 in a test environment gets promoted to production unchanged. A certificate expires on a protected subdomain. Without scanning, these failures are invisible.
Inventory first, enforce second.
Before activatingincludeSubDomains, you need a complete, verified list of every subdomain that resolves for your domain — and confirmation that each one has a valid, publicly-trusted TLS certificate. This is not a one-time audit. Certificate renewals, new subdomains, and infrastructure changes all require ongoing monitoring.
The correct rollout order: enumerate subdomains → verify TLS on each → fix any gaps → add HSTS withmax-age=300→ monitor for two weeks → increase max-age → addincludeSubDomains→ monitor again → consider preload submission.
5Verification & Audit: The DomainRisk Approach
DomainRisk.io evaluates HSTS enforcement as part of every domain scan — across the apex domain and all discovered subdomains — and factors the result directly into your domain's security score.
HSTS header presence
Header detectedThe scanner performs an HTTPS request to the apex domain and checks for the Strict-Transport-Security response header. Absence is flagged as a high-severity finding.
max-age adequacy
>= 1 year = compliantA max-age below 10,886,400 seconds (18 weeks - the minimum for hstspreload.org submission) is flagged as insufficient. A max-age below 31,536,000 (1 year) is flagged as medium severity.
includeSubDomains directive
Subdomains coveredChecked independently. Missing on a domain with multiple subdomains generates a medium finding - partial coverage is not full protection.
Preload directive & list status
Preload confirmedThe scanner checks whether preload is declared in the header and whether the domain is confirmed on the Chrome HSTS preload list. Declared but not submitted is flagged.
Subdomain TLS consistency
All subdomains validFor every discovered subdomain, the scanner verifies a valid, unexpired, hostname-matching TLS certificate exists - a prerequisite before enabling includeSubDomains safely.
Is your HSTS configuration production-ready?
Get a complete Audit Report — HSTS enforcement, subdomain TLS inventory, DMARC, MTA-STS, SPF, DKIM and 30+ additional risk factors — in under 60 seconds. Free scan, no credit card required.
6Conclusion: Security is a Chain
SSL is the link. HSTS is the weld.
A chain is only as strong as its weakest link — and a chain with an open link is not a chain at all. SSL/TLS secures the data in transit. HSTS ensures the encrypted channel is theonlychannel that can ever be opened. Together, they close every gap that SSL Stripping exploits. Separately, SSL alone leaves the first connection perpetually exposed.
Implementing HSTS correctly requires three things: the header itself, enough max-age to matter, and the subdomain inventory to makeincludeSubDomainssafe. None of these are technically difficult. All of them require visibility into your infrastructure that most teams do not have by default.
The first step is always a complete scan: does your apex domain have HSTS? Is the max-age adequate? Which subdomains are missing TLS? DomainRisk.io answers all three questions in a single free scan — and tracks them continuously so a certificate renewal failure or a new subdomain without TLS never becomes a silent vulnerability.