TL;DR: When a user types
example.com, the browser often starts with plain HTTP and is redirected to HTTPS. A man in the middle can intercept that first HTTP request and keep the victim on HTTP, talking HTTPS to the real site on their behalf (SSL stripping). HTTP Strict Transport Security is a response header (Strict-Transport-Security: max-age=...; includeSubDomains) that tells the browser to use only HTTPS for the domain for the given time and to make certificate errors non-bypassable. The first visit remains exposed, which the HSTS preload list fixes by shipping the domain in browsers. The risks are operational:includeSubDomainsand preload apply to every subdomain, including internal ones that never had HTTPS, and removal from the preload list takes months.
How to approach it
Describe the attack as a sequence (first request over HTTP, attacker relays), then HSTS's two effects (upgrade and no click-through), then the trust-on-first-use gap and preloading, then deployment risks. Interviewers like this question because it tests both protocol understanding and operational judgement.
A strong answer
No HSTS
User types bank.com
browser tries http://
Attacker on path
answers over HTTP
Never forwards the redirect to HTTPS
Real site
attacker talks HTTPS to it
Outcome, unsafe: Victim stays on HTTP
Passwords and cookies visible to the attacker
HSTS or preload
User types bank.com
browser knows the policy
Upgrades to https:// internally
Attacker on path
only sees TLS
Cannot present a valid certificate
Real site
direct TLS
Outcome, safe: No plaintext request exists
Certificate errors cannot be clicked through
The attack. The victim on a hostile network types bank.example. The browser sends GET http://bank.example/. The attacker intercepts, fetches the HTTPS site themselves, and returns pages to the victim over HTTP with links and form actions rewritten to HTTP. The victim sees a working site with no padlock and submits credentials in clear text. TLS was never broken; it was never used on the victim's side. Variants downgrade only part of a page or strip Secure flags from cookies.
What HSTS does. After the browser receives the header over a valid HTTPS connection:
- For
max-ageseconds, every request to that host (and its subdomains withincludeSubDomains) is upgraded to HTTPS inside the browser before it is sent. No plain HTTP request leaves. - Certificate errors for the host become fatal: the user cannot click through. This removes the second most common way MITM succeeds.
The header is ignored over plain HTTP, so an attacker cannot set or clear it by injecting into HTTP responses.
The first-visit gap and preloading. Before the browser has seen the header (new device, cleared data, expired max-age), the first request can still be stripped. The HSTS preload list, maintained for Chromium and used by other major browsers, hard-codes domains as HTTPS-only. Requirements include serving the header with a long max-age (at least one year), includeSubDomains and the preload token, and redirecting HTTP to HTTPS on the same host. Some top-level domains are preloaded as a whole (for example .dev and .app), so every site under them is HTTPS-only by default.
Deployment risks.
includeSubDomainsbreaks any subdomain that does not serve valid HTTPS: intranet hosts, legacy devices, printers with web interfaces under the corporate domain.- Preloading is slow to undo: removal requests take effect only as browser releases ship, so a mistake persists for months.
- A long
max-agewith a broken certificate means users cannot reach the site at all, rather than clicking through. That is the intended security property and an availability risk.
Roll out gradually: start with a short max-age without includeSubDomains, inventory subdomains, fix their HTTPS, extend max-age, then add includeSubDomains, then preload.
Related controls. Set Secure on cookies so they never travel over HTTP; use __Host- cookie prefixes to bind cookies to the host over HTTPS; avoid mixed content. For mobile apps, the equivalents are network security configuration (Android) and App Transport Security (iOS), which block cleartext by default.
What interviewers probe next
- "Can an attacker remove HSTS by sending max-age=0?" Only over a valid HTTPS connection to the real site, which they cannot establish without a trusted certificate.
- "Does HSTS protect APIs called by mobile apps?" No, it is a browser mechanism; apps should enforce HTTPS themselves, which the platforms do by default.
- "What if the site's certificate expires with HSTS on?" Browsers refuse to connect and users cannot override, so certificate automation and monitoring become availability-critical.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Your site redirects HTTP to HTTPS, and a tester on the same café network still captures a user's session cookie.
Start here
How did the tester capture the cookie?
What happens before the redirect?
The browser often starts with plain HTTP and is redirected. An on-path attacker intercepts that first HTTP request and keeps the victim on HTTP while talking HTTPS to the real site, which is SSL stripping. A cookie without Secure travels in clear.
Carry it forwardThe first HTTP request is the weak point.
Weak answerThinking a redirect is enough.
Constraint changes
What does HSTS do?
What does the browser remember?
It is a response header that tells the browser to use only HTTPS for the domain for max-age seconds, optionally including subdomains. After the first visit, the browser never makes the plain HTTP request again and refuses certificate errors.
Carry it forwardHSTS makes the browser use HTTPS only.
Weak answerSetting a tiny max-age.
Constraint changes
What about the very first visit?
How does a new browser know?
Without a stored policy the first visit is still exposed. HSTS preloading puts the domain in browsers' built-in lists, so even the first request uses HTTPS. Preloading needs includeSubDomains and is hard to undo.
Carry it forwardPreload closes the first-visit gap.
Weak answerPreloading before all subdomains support HTTPS.
Constraint changes
What else would have protected the cookie?
Should a session cookie ever travel over HTTP?
The Secure attribute, so it is never sent over HTTP, and the __Host- prefix to stop subdomains overwriting it. These matter even with HSTS.
Carry it forwardSecure cookies never travel over HTTP.
Weak answerRelying on HSTS alone for cookies.
Constraint changes
How do you roll out HSTS safely?
Which subdomains still use HTTP?
Inventory subdomains to confirm HTTPS works everywhere, start with a short max-age, increase it, add includeSubDomains, then submit for preload. Monitor for broken subdomains along the way.
Carry it forwardRoll out HSTS gradually with inventory.
Weak answerJumping to preload without checks.
Now defend it
How would you fix the issue?
Set Secure, HttpOnly and __Host- on the session cookie; deploy HSTS with a long max-age and includeSubDomains after confirming every subdomain supports HTTPS; then preload the domain; and keep the HTTP-to-HTTPS redirect for clients without HSTS.
How it's scored
Weak: "HSTS forces HTTPS."
Hire: Explains SSL stripping on the first request, HSTS's upgrade and non-bypassable errors, and preloading for the first visit.
Strong Hire: Walks the attack precisely, explains why the header is honoured only over HTTPS, gives preload requirements and TLD preloading, details includeSubDomains and removal risks with a staged rollout, and connects to cookie flags and mobile equivalents.
Common mistakes
- Believing an HTTP-to-HTTPS redirect is enough.
- Enabling
includeSubDomainsand preload without inventorying subdomains. - Forgetting the first-visit gap.
- Treating HSTS as relevant to non-browser clients.