WEBINVEST.IT
Glossary

HSTS

HSTS, or HTTP Strict Transport Security, is a policy that a website communicates to the browser via the HTTP Strict-Transport-Security header. Once a browser receives a valid HSTS policy from an HTTPS site, it remembers that for the domain, it must use HTTPS for future visits during the specified period. This reduces the chance of a connection being initiated in plaintext and helps defend against downgrade or interception attacks on networks. HSTS does not install a certificate or secure a misconfigured server; it assumes HTTPS is already properly set up.

How the Header Works

The header includes directives such as max-age, which defines how long the browser stores the policy, and can include includeSubDomains to extend it to subdomains. A preload option signals intent to be included in compatible browsers’ preloaded lists, but requires specific criteria and a separate process. Simply adding preload to the header does not automatically include the domain. An incorrect policy may block access to subdomains that do not support HTTPS or have invalid certificates.

Browsers enforce HSTS locally and can convert an HTTP request to HTTPS before contacting the server. Users typically cannot easily bypass certificate errors for a covered domain, as the policy is designed to prevent insecure fallbacks. The first visit may remain exposed if the domain is not preloaded and the browser has not yet received the header; HTTPS links and preload can reduce this window but must be planned carefully.

Prerequisites and Rollout

Before enabling HSTS, all involved hostnames must work correctly over HTTPS: the main domain, www, subdomains used by apps, login pages, support, or third-party services. Certificates, auto-renewals, redirects, mixed content, and monitoring must be verified. The max-age can initially be set to a short period and increased after testing; includeSubDomains and preload are broader choices that are harder to reverse quickly. An abandoned or externally managed subdomain may become inaccessible if it inherits the policy without valid HTTPS.

If a browser has stored a long HSTS policy, removing the header from the server does not immediately clear the local copy. To revoke HSTS, send max-age=0 over HTTPS; however, the client must receive the response, and preloaded lists follow an independent process. Therefore, enabling HSTS should be treated as a security change with rollback plans and a subdomain inventory—not a setting to enable blindly.

HSTS and Other Controls

HSTS is distinct from TLS, certificates, and redirects. TLS encrypts the connection; certificates authenticate the name according to the trust chain; an HTTP redirect to HTTPS forwards a request but leaves the initial one in plaintext. HSTS instructs the browser to use HTTPS for future visits. This protection does not replace MFA, application security, CSP, or DNS management. If a domain is compromised and an attacker controls a valid certificate, HSTS alone does not ensure users reach the legitimate service.

Verification uses tools that check headers and browser behavior, but real-world subdomain and environment testing is essential. Max-age, includeSubDomains, certificates, redirects, and compatibility are all validated. In summary, HSTS strengthens the browser’s HTTPS preference and reduces downgrade risks, but requires full TLS coverage and careful planning—especially before expanding the policy or requesting preload.

← Full glossary