HSTS

Why it matters

Without it, a visitor's very first request to a site, before any redirect has a chance to run, can be made over unencrypted HTTP and is briefly exposed to interception, a gap known as SSL stripping. HSTS closes that specific window by making the browser refuse to even attempt the insecure connection after the first visit. It also protects against a specific, low-tech attack: a visitor on public wifi typing a domain without 'https://' can otherwise be silently downgraded to an unencrypted connection before any redirect logic even runs. It also has a preload list option, submitting a domain to browsers directly so protection applies even on a visitor's very first-ever visit, before the site has had a chance to set the header at all.

What goes wrong when it's handled badly

A site with HTTPS but no HSTS header is still vulnerable to that first-connection gap, which is easy to overlook since the site otherwise appears fully secure. Enabling HSTS with a very long duration before confirming HTTPS is fully and permanently working everywhere on the domain can also lock out visitors if something later needs to run over plain HTTP, so it is rolled out deliberately. A concrete example is a site migrating domains that forgets to carry its HSTS preload status across, briefly reopening the exact insecure-connection window the header exists to close, right at the moment of a migration when traffic and scrutiny are both highest. Testing the header is actually present and correctly configured after every infrastructure change, not assuming it persists automatically, is what catches this class of regression.