Missing HTTP Strict Transport Security (HSTS) Header

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / Transport Layer Protection
Typical Severity Medium
OWASP A05:2021 – Security Misconfiguration
CWE CWE-319 – Cleartext Transmission of Sensitive Information
Relevant RFC RFC 6797 – HTTP Strict Transport Security (HSTS)
Also known as Missing HSTS, No Strict-Transport-Security header, HSTS not set
Affected systems Any HTTPS-enabled web application or API endpoint missing the Strict-Transport-Security response header

Overview

HTTP Strict Transport Security (HSTS) is a web security policy mechanism defined in RFC 6797 that instructs browsers to interact with a site exclusively over HTTPS for a declared period. When the Strict-Transport-Security response header is absent, browsers treat HTTP and HTTPS as equally acceptable transports, leaving users vulnerable to SSL-stripping attacks and unintended cleartext communication — even if the server enforces redirects from HTTP to HTTPS.

Sensagraph automatically detects missing or misconfigured HSTS headers during its continuous scanning of web properties.

How it works

Without HSTS, the following attack surface exists:

  • First-visit exposure: A user's first request to a site (or a request made after the HSTS cache entry expires) is typically sent as plain HTTP before any server redirect to HTTPS. An on-path attacker can intercept this initial request.
  • SSL stripping: An attacker performing a man-in-the-middle (MitM) attack can silently downgrade an HTTPS connection to HTTP using tools like sslstrip. The server issues a 301/302 redirect, but the attacker intercepts it and proxies the connection over HTTP, while maintaining an HTTPS session with the server. The victim's browser receives only HTTP.
  • Mixed-content and bookmark issues: Users who bookmarked or typed the http:// variant bypass HTTPS entirely, and without HSTS there is no browser-enforced upgrade.
  • Cookie theft: Session cookies not marked with the Secure flag can be transmitted over the downgraded HTTP connection, allowing session hijacking.
  • Expired or missing max-age: A header present with max-age=0 effectively revokes HSTS, creating the same risk as its complete absence.

The Strict-Transport-Security header syntax is:

Strict-Transport-Security: max-age=<seconds>[; includeSubDomains][; preload]

Once a browser receives a valid HSTS header, it will automatically upgrade all future HTTP requests to HTTPS for the domain for the duration of max-age, without making an initial HTTP request.

Business impact

The absence of HSTS can have significant consequences, particularly for applications that handle authentication, payments, or personal data:

  • Credential and session theft: Attackers on shared networks (e.g., public Wi-Fi) can intercept login credentials and session tokens via SSL stripping or passive eavesdropping on HTTP traffic.
  • Data integrity violation: Content served over HTTP can be injected with malicious scripts, advertisements, or redirects by a MitM attacker.
  • Regulatory and compliance risk: PCI DSS, HIPAA, and GDPR mandates for data-in-transit protection may be considered unmet if transport security controls are weak or bypassable.
  • Reputational damage: A successful MitM attack that exposes user data can erode customer trust and trigger public disclosure obligations.

How to fix it

  1. Set the Strict-Transport-Security header on all HTTPS responses. Configure the header at the web server or application layer. A minimum recommended max-age is 31536000 seconds (one year): 
    Strict-Transport-Security: max-age=31536000; includeSubDomains
  2. Include includeSubDomains to extend HSTS enforcement to all subdomains, preventing attackers from bypassing HSTS by targeting a subdomain over HTTP.
  3. Add the preload directive and submit your domain to the HSTS Preload List to eliminate first-visit vulnerability. Note that preloading requires includeSubDomains and a max-age of at least 31536000.
  4. Ensure the header is sent only over HTTPS. Sending HSTS over HTTP is ignored by browsers and may cause configuration issues; send it exclusively from HTTPS responses.
  5. Do not set max-age=0 except when intentionally revoking HSTS (e.g., prior to decommissioning HTTPS on a domain).
  6. Ensure all HTTP traffic is redirected to HTTPS (HTTP 301) before relying on HSTS, so that the header is ultimately delivered to all clients.
  7. Verify configuration in major web servers:
    • Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    • Apache: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    • IIS: Add a custom response header via the HTTP Response Headers feature or web.config.

References

Frequently asked questions

No. HTTP-to-HTTPS redirects only protect users after the first request reaches the server. An attacker positioned on the network can intercept that initial HTTP request before the redirect is received. HSTS instructs the browser to skip HTTP entirely for subsequent visits, eliminating this window of exposure.

RFC 6797 does not prescribe a minimum, but security best practices and HSTS preload list requirements specify a minimum of 31536000 seconds (one year). Shorter values reduce the window of protection and increase exposure during browser cache expiry.

Only if all subdomains of your domain are accessible exclusively over HTTPS. Adding includeSubDomains while some subdomains still serve HTTP-only content will break access to those subdomains for users whose browsers have cached the HSTS policy.

HSTS preloading embeds your domain in a list that is compiled directly into browsers (Chrome, Firefox, Safari, Edge). This eliminates first-visit vulnerability entirely, because the browser enforces HTTPS even before it has ever connected to your site and received an HSTS header.

Yes. Many frameworks (e.g., Django's SECURE_HSTS_SECONDS setting, Spring Security's hsts() configuration, ASP.NET Core's UseHsts() middleware) support HSTS header injection at the application layer. Either approach is valid, but server-level configuration typically covers all responses including static assets and error pages.