Cybersecurity 101back-iconWhat is HTTP Strict Transport Security (HSTS)?

What is HTTP Strict Transport Security (HSTS)?

HTTP Strict Transport Security (HSTS) is a web security policy that tells browsers to connect to a website only over HTTPS, even if a user or application tries to load it over HTTP. In simple terms, HSTS HTTPS enforcement helps prevent browsers from falling back to an insecure connection.

When a site sends the HSTS response header, supported browsers remember that rule for a defined period. During that time, the browser automatically upgrades HTTP requests to HTTPS before sending them across the network.

How HSTS HTTPS protection works

HSTS is delivered through the Strict-Transport-Security HTTP response header. A basic version looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

The max-age value tells the browser how long to enforce HTTPS for that domain. The optional includeSubDomains directive extends the rule to subdomains. Some sites also use preload, which signals intent to be included in browser-maintained HSTS preload lists.

Directive What it does
max-age Sets how long the browser must enforce HTTPS.
includeSubDomains Applies the policy to all subdomains.
preload Supports submission to browser HSTS preload programs.

Why HSTS matters for application security

Without HSTS, users may still be exposed during the first insecure HTTP request, especially on public Wi-Fi or compromised networks. Attackers can try SSL stripping, where they force a browser to use HTTP and intercept or modify traffic.

HSTS reduces that risk by making HTTPS the default behavior after the browser has received the policy. For business applications, APIs, admin portals, and software delivery systems, this helps protect credentials, session cookies, tokens, and update channels from downgrade attacks.

Where HTTPS HSTS fits in software supply chain security

HSTS does not replace TLS certificates, secure coding, API authentication, or dependency controls. Instead, it strengthens the transport layer for web-facing services that support development, deployment, and device management workflows.

For example, organizations using platforms such as Hexnode to manage endpoints still need secure browser sessions, trusted admin access, and protected web communication. HSTS contributes to that baseline by reducing accidental or forced use of unsecured HTTP.

Best practices for enabling HSTS

Before enabling HSTS widely, confirm that the website and required subdomains work correctly over HTTPS. A strict HSTS policy can break access to subdomains that are not HTTPS-ready.

  • Use valid, trusted TLS certificates across the domain.
  • Start with a shorter max-age during testing.
  • Add includeSubDomains only after verifying all subdomains.
  • Consider preload only when HTTPS coverage is mature.
  • Monitor redirects, APIs, CDNs, and legacy integrations after rollout.

What HSTS does not protect against

HSTS cannot fix weak TLS configuration, compromised certificates, vulnerable application code, or phishing domains that use valid HTTPS. It also does not encrypt data by itself; HTTPS does that. HSTS simply ensures that browsers keep using HTTPS once the policy is known.

FAQs

No. HTTPS encrypts the connection, while HSTS tells browsers to always use HTTPS for a specific site.

Yes, if API clients behave like browsers or respect HSTS policies. However, many server-to-server API clients require separate HTTPS enforcement and certificate validation controls.

Not immediately. Preload is hard to reverse quickly, so organizations should use it only after confirming stable HTTPS support across the domain and subdomains.