Get fresh insights, pro tips, and thought starters–only the best of posts for you.
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.
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. |
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.
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.
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.
max-age during testing.includeSubDomains only after verifying all subdomains.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.
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.