What Does “Strict-Transport-Security Header Not Set” Mean?

How Scanners Detect This Finding

HSTS scanners generally evaluate HTTPS responses and look for a syntactically valid Strict-Transport-Security header with a usable max-age. Related checks may separately flag malformed values, missing max-age, duplicate headers, disabled policies, or a header sent over HTTP where browsers will not honor it.

That distinction matters during remediation. A site can “have an HSTS header” and still fail practical validation because the value is malformed or sent from the wrong listener. Test the externally reachable HTTPS response generated after every proxy, CDN, or load balancer in the path.

Practical Security Scenario

Imagine a user on an untrusted Wi-Fi network who types example.com without specifying HTTPS. If the browser has never learned an HSTS policy and the domain is not preloaded, the first HTTP request can be exposed to an on-path attacker before the server redirects to HTTPS. HSTS reduces that downgrade window after the browser has learned the policy.

Now consider the operational side: if includeSubDomains covers a forgotten legacy host with no valid certificate, users can no longer fall back to HTTP and cannot safely bypass the certificate error. This is why HSTS rollout must combine security goals with hostname inventory and certificate lifecycle discipline.

Where This Control Should Be Applied

Apply HSTS to HTTPS origins that are intended to remain HTTPS-only. It is especially appropriate for authenticated web applications, customer portals, API documentation, and public sites where every supported browser connection should use TLS.

Before extending the policy to subdomains, inventory wildcard DNS, legacy applications, temporary environments, third-party hosted subdomains, and service endpoints. If some subdomains cannot commit to HTTPS, do not use includeSubDomains until that dependency is resolved. Preload should be treated as an additional, deliberate commitment rather than a generic best-practice suffix.

Why Missing HSTS Matters

HTTPS redirection and HSTS solve different problems. A 301 or 308 redirect only helps after an HTTP request reaches the server. HSTS can cause a browser that already knows the policy to upgrade the URL before that plaintext HTTP request is sent.

This distinction matters on hostile or untrusted networks where an attacker may attempt SSL stripping or downgrade behavior. HSTS reduces that first-hop downgrade opportunity for returning users and, when a domain is included in browser preload lists, can also protect the first visit.

HSTS does not repair weak TLS, expired certificates, mixed content, insecure cookies, or application vulnerabilities. It is one part of an HTTPS deployment and should be introduced only after the covered hostnames reliably support HTTPS.

How HSTS Directives Work

• max-age: Required. The number of seconds the browser should remember the HSTS policy.
• includeSubDomains: Extends the policy to subdomains. Use only when every relevant subdomain can remain HTTPS-only.
• preload: Signals intent for browser preload programs. It is not an automatic preload registration mechanism and should not be added casually.
• HTTPS responses only: Browsers ignore HSTS received over plain HTTP because an attacker could tamper with that response.
• Certificate errors: For a known HSTS host, users should not be allowed to click through invalid certificate warnings.

Related Ammune guides: HTTP security header not detected, API gateway vs reverse proxy, and OWASP API8:2023 Security Misconfiguration.

A Common HSTS Header

A mature HTTPS-only domain may eventually use a policy such as:

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

Common Remediation Mistakes

• Sending HSTS only on the HTTP redirect response instead of the HTTPS response.
• Starting immediately with a one- or two-year max-age across all subdomains before legacy hosts are ready.
• Adding includeSubDomains while forgotten internal, vendor, or legacy subdomains still require HTTP.
• Adding preload without understanding browser preload submission and removal timelines.
• Assuming HSTS fixes mixed content, weak ciphers, certificate lifecycle problems, or insecure application logic.
• Forgetting error responses and alternate virtual hosts that may be served over HTTPS.

How to Fix HSTS Header Not Set Without Breaking Subdomains

1. Inventory HTTPS coverage. List the production hostname, aliases, legacy subdomains, vendor-managed hosts, alternate ports, and any domain that could be affected by includeSubDomains. Confirm valid certificates and HTTPS service on every host you intend to cover.

2. Start on the intended HTTPS host. Set a modest max-age first and verify the header appears on normal, redirected, authenticated, and error responses generated over HTTPS.

3. Increase max-age after operational validation. Once certificate renewal, redirects, monitoring, and rollback procedures are proven, increase the duration to the organization’s target policy rather than treating the first scanner pass as the end state.

4. Add includeSubDomains only when the zone is ready. This directive extends the policy to subdomains even when they do not explicitly send HSTS themselves. Forgotten HTTP-only hosts can become unreachable in compliant browsers.

5. Treat preload as a separate commitment. If preload is desired, review the current browser preload requirements and removal process before submitting. Preload changes first-visit behavior and is intentionally harder to reverse than a normal response header.

Configuration Examples

Set HSTS at the internet-facing layer that reliably owns the final HTTPS response. A reverse proxy, gateway, CDN, or load balancer may be a better owner than the application if it terminates TLS for every route. Avoid duplicate HSTS headers and verify that the same edge layer does not inject the header into plain HTTP responses.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Configure HSTS on the internet-facing layer that produces the final HTTPS response, and verify that downstream and edge configuration do not create duplicate or conflicting headers.

How to Test the Fix

1. Request the production HTTPS URL and confirm a single valid Strict-Transport-Security header is present.
2. Confirm the header is not being relied on from an HTTP response; browsers only accept HSTS over secure transport.
3. Inventory subdomains before adding includeSubDomains, including legacy portals, mail/webmail, vendor callbacks, static hosts, and temporary environments.
4. Test certificate renewal and failure handling because HSTS makes certificate mistakes more disruptive to users.
5. Re-run the scanner and inspect related HSTS findings such as missing max-age, malformed values, duplicate entries, or HSTS delivered on plain HTTP.

Test with a clean client and inspect the HTTPS response directly. Confirm a single parseable max-age, then separately verify subdomains before adding includeSubDomains. A scanner can confirm header syntax; only environment inventory can prove that a long-lived policy will not strand a legacy host.

How to Think About Severity

ZAP rates a missing HSTS header as Low. The finding is not equivalent to broken TLS: an HTTPS site can have strong encryption and still lack HSTS. The additional risk is that a user who has not yet learned the policy may be steered toward HTTP on an untrusted network before the secure redirect is reached.

Risk is lower for hosts that are already preloaded or never reachable over HTTP, and higher for public applications where users may type the bare domain or follow HTTP links from hostile networks. HSTS should be one layer in a complete HTTPS posture that also includes certificate lifecycle management, modern TLS configuration, and removal of mixed content.

How Ammune Fits

HSTS protects the transport decision made by browsers. Ammune operates after traffic reaches the application security layer, where it can provide API discovery, runtime analysis, abuse detection, and visibility into sensitive data.

An HTTPS-only connection can still carry an unauthorized object request, credential abuse, business-logic automation, or excessive data exposure. HSTS secures the path; API security must still evaluate what the request is allowed to do once it arrives.

Production Remediation Checklist

• Confirm the finding is on an HTTPS response and identify the TLS termination layer.
• Verify certificate validity and renewal automation before committing to a long max-age.
• Start with a limited max-age during rollout and increase it after validation.
• Confirm HSTS is not being relied on from an HTTP response.
• Inventory every subdomain before enabling includeSubDomains.
• Treat preload as an independent operational decision with its own rollback implications.
• Test 200, redirects, authentication failures, 404s, and edge-generated error pages.
• Check for duplicate or malformed HSTS headers.
• Re-run ZAP and review the other 10035 HSTS syntax/configuration findings separately.
• Monitor certificate and HTTPS availability continuously after deployment.

Frequently Asked Questions

Primary References