HSTS

Overview

HTTP Strict Transport Security (HSTS) is a response header that forces browsers to use HTTPS for a site, protecting against downgrade and interception attacks. This lesson covers HSTS.

Learning objectives

• Explain what HSTS enforces.
• Describe the risks it mitigates.
• Understand its directives and cautions.

Core concept

HSTS (Strict-Transport-Security header) instructs the browser to only connect to the site over HTTPS for a specified duration, refusing plain HTTP. Directives include max-age (how long to enforce, in seconds), optionally includeSubDomains (apply to subdomains), and preload (eligibility for browsers' built-in preload lists). Once a browser has seen a valid HSTS header, it upgrades any HTTP attempt to HTTPS automatically and blocks bypassing certificate warnings.

How it works

Without HSTS, a user typing the domain (or following an http:// link) makes an initial insecure request that an on-path attacker could intercept or downgrade (an SSL-stripping attack) before any redirect to HTTPS. HSTS closes this by making the browser remember to use HTTPS for max-age, so subsequent visits go straight to HTTPS with no insecure hop. includeSubDomains extends protection to subdomains, and preload (with careful, deliberate opt-in) hardcodes the policy into browsers so even the very first visit is protected. Because it is sticky, a too-broad or premature HSTS (especially with preload/includeSubDomains) can cause problems if not all subdomains support HTTPS.

Practical example

A site sends Strict-Transport-Security: max-age=63072000; includeSubDomains. After the browser records this, any attempt to reach the site (or its subdomains) over http:// is automatically upgraded to HTTPS, and users cannot click through certificate warnings — defeating downgrade/SSL-stripping attempts. The site's operators enable includeSubDomains (and consider preload) only after confirming all subdomains support HTTPS, to avoid locking out any that do not.

Cybersecurity relevance

HSTS defends against protocol-downgrade and SSL-stripping man-in-the-middle attacks and enforces encryption consistently — a recommended header for HTTPS sites. Its absence is a common finding on sites that support HTTPS but do not enforce it. Cautions matter: because HSTS is sticky and preload is hard to reverse quickly, operators enable broad scope only when confident in full HTTPS support. Defenders set an appropriate max-age (and scope) after ensuring HTTPS everywhere; testers check whether HSTS is present and adequately configured.

Common mistakes

• Not sending HSTS on an HTTPS site, leaving a downgrade/SSL-stripping window.
• Enabling includeSubDomains/preload before all subdomains support HTTPS, causing outages.
• Setting an extremely short max-age, weakening the protection.

Key takeaways

• HSTS forces browsers to use HTTPS for a site for max-age, refusing plain HTTP and blocking certificate-warning bypass.
• It mitigates protocol-downgrade and SSL-stripping man-in-the-middle attacks; includeSubDomains and preload extend it (with care).
• Enable it (with appropriate scope) only after ensuring full HTTPS support, since it is sticky and preload is hard to reverse; its absence is a common finding.

Check your understanding

• What attack does HSTS mitigate that a simple HTTP-to-HTTPS redirect does not fully prevent?
• Why should includeSubDomains/preload be enabled only after confirming all subdomains support HTTPS?