Strict-Transport-Security Header

ID

strict_transport_security_header

Severity

low

Kind

Security Misconfiguration

CWE

319

Description

HTTP Strict Transport Security (HSTS) is a security policy mechanism defined in RFC 6797 that instructs browsers to interact with a server exclusively over HTTPS connections. When the Strict-Transport-Security header is missing or misconfigured, the application fails to enforce transport-layer encryption, leaving users vulnerable to protocol downgrade and man-in-the-middle attacks. Several sub-variants of this misconfiguration exist, each representing a different way the HSTS policy can be absent or improperly applied.

  • Header not set: the server does not include a Strict-Transport-Security header in its HTTPS responses, so browsers never activate HSTS protection for the domain.

  • HSTS disabled via max-age=0: the header is present but contains the directive max-age=0, which instructs browsers to clear any previously cached HSTS policy for the domain.

  • Multiple header entries: the response contains more than one Strict-Transport-Security header, which is non-compliant with RFC 6797. Only the first entry is processed by browsers, and the policy may be applied incorrectly.

  • Header on plain HTTP response: the Strict-Transport-Security header appears on an unencrypted HTTP response. Browsers ignore HSTS directives received over insecure connections, so the header has no effect.

  • Missing max-age directive: the header is present but lacks the required max-age directive or its value, making it non-compliant with the specification.

  • Defined via META tag: HSTS is declared through an HTML META tag instead of an HTTP response header. The specification explicitly does not support this mechanism.

  • Malformed max-age directive: the max-age directive is preceded by quotes or contains unexpected formatting, making it non-compliant with RFC 6797.

  • Malformed content: the header contains non-printable or unexpected characters such as curly quotes, deviating from the expected printable ASCII content.

Rationale

Without a properly configured HSTS header, an attacker in a privileged network position can perform SSL stripping attacks, intercepting the initial HTTP request before the browser upgrades to HTTPS and forcing all subsequent communication over an insecure channel. This allows the attacker to capture sensitive data such as login credentials, session cookies, and personal information transmitted between the user and the server. Additionally, the absence of HSTS enables cookie hijacking on connections that briefly fall back to HTTP, since session tokens sent without encryption can be read and replayed by an adversary.

Remediation

Ensure that every HTTPS response from your web server, application server, or load balancer includes a single, well-formed Strict-Transport-Security header with an appropriate max-age value. A minimum of 31536000 seconds (one year) is recommended, and for broader protection the includeSubDomains directive should be added so the policy covers all subdomains.

Before enabling HSTS, verify that all subdomains and resources are accessible over HTTPS, since browsers will refuse insecure connections once the policy is active. Do not send the header over plain HTTP, do not define it via HTML META tags, and avoid setting max-age=0 unless you intentionally need to disable a previously deployed policy.

For sites that require the strongest guarantee, consider submitting the domain to the HSTS preload list. This requires a max-age of at least 31536000 seconds, the includeSubDomains directive, and the preload directive, ensuring browsers enforce HTTPS even on the very first visit.

References