In one paragraph
A missing Strict-Transport-Security header means this HTTPS response does not teach browsers to require HTTPS for future visits. HSTS reduces downgrade exposure after a browser learns the policy and prevents bypassing relevant certificate errors. Start with a tested host-only policy, increase its lifetime when HTTPS is reliable, and assess subdomains separately before enabling includeSubDomains or requesting preload inclusion.
Why it matters
An HTTP-to-HTTPS redirect is a server response to a request that has already happened. HSTS lets a browser upgrade an applicable HTTP URL internally before sending it. This helps against network attackers who would otherwise interfere with a visitor's initial plaintext navigation.
HSTS is learned from a secure response. Without prior knowledge or a preload entry, it does not protect the first HTTP contact by itself. Modern HTTPS-first navigation can reduce that exposure, but is a separate browser feature, not a substitute for configuring your own policy.
The max-age value sets how long the browser should remember the policy. Receipt of a fresh valid header updates its expiry. Omitting the header on a later response does not immediately erase an existing policy, and an inherited parent-domain policy can apply even when this individual response sends none.
How WebAuditOS evaluates this finding
The supplied check examines HTTPS response headers. No Strict-Transport-Security header fails. A max-age below 15,768,000 seconds receives a warning, while that threshold or higher passes. HTTP responses and requests with no response are not graded.
That six-month threshold is the scanner's acceptance criterion, not the point at which browsers begin enforcing HSTS. A short positive lifetime can already enforce the policy. The header's presence on one response also does not prove every hostname is covered or that the domain has been preloaded.
How to fix it
- Confirm stable HTTPS and certificate renewal before committing browsers. Test the hostname's important pages and services, not only a successful homepage load.
- Start with a host-only short lifetime during a controlled rollout. For example:
Strict-Transport-Security: max-age=86400This example requests one day of protection for the issuing host without automatically including its subdomains. It can intentionally remain below the scanner's passing threshold while you validate the rollout.
- Set the header on HTTPS responses at the appropriate application, proxy, or CDN layer. For nginx, an illustrative rule inside the applicable HTTPS server configuration is:
add_header Strict-Transport-Security "max-age=86400" always;Check your server version's header inheritance and any route-specific overrides. Do not assume the directive covers a separate asset hostname or a different virtual host.
- Increase the lifetime after testing. A one-year host-only value is:
Strict-Transport-Security: max-age=31536000Choose the duration deliberately. Continue to support working HTTPS throughout the policy lifetime already cached by visitors.
- Inventory subdomains before adding includeSubDomains. A policy from example.com can cover descendants; a policy from www.example.com does not cover the apex or sibling app.example.com. Verify delegated services, forgotten staging hosts, and any HTTP-only browser interfaces within the intended scope.
- Treat preload as a separate project. Adding the preload token does not instantly enrol the domain. Review current eligibility and submit through the preload service only when ready. The published requirements include a sufficiently long max-age and includeSubDomains, along with other live checks.
- Inspect response headers from the public HTTPS endpoint and rescan relevant URLs. Verify subdomains independently rather than equating one passing page with full estate coverage. Keep certificate-expiry monitoring independent of the HSTS configuration.
What the fix can break
HSTS prevents access through relevant certificate errors instead of letting the visitor click through. An expired or misconfigured certificate can therefore create a hard outage for affected browsers. That is a reason to improve renewal and monitoring, not to depend on users bypassing warnings.
includeSubDomains can break HTTP-only descendant sites once the parent policy applies. A short host-only trial does not test that wider scope; validate it explicitly before enabling it.
Rollback requires continued valid HTTPS. A valid max-age=0 response can clear that host's dynamic policy when a browser receives it, but removing the header alone does not clear cached state. Independently learned subdomain policies, inherited parent policies, and preload state require separate consideration. Waiting one day after deleting a config line does not guarantee every browser has recovered.
Questions
Does HSTS work when sent over HTTP?
No. Browsers ignore an HSTS header received over an insecure connection. Deliver it through a valid HTTPS response.
Should I copy includeSubDomains and preload immediately?
No. Both require broader readiness than one working hostname. Start with a policy whose scope you understand, then assess subdomain and preload commitments separately.
Does max-age=0 instantly remove every HSTS restriction?
No. It affects dynamic policy for that host when received over valid HTTPS. It does not automatically remove a parent policy, independently stored child policies, or browser preload entries.
What should I review alongside HSTS?
Review Content-Security-Policy, the security headers guide, and the website audit checklist. HSTS protects transport selection, not script execution.