When HSTS takes effect
HTTP Strict Transport Security (HSTS) is a browser policy for a host. The browser must already know it: from a valid HTTPS response from that host, an applicable includeSubDomains policy of a parent host, or its preload list. It then changes an HTTP request to HTTPS before accessing the network. RFC 6797, section 8
An HTTP redirect works differently: the server first answers an HTTP request and names an HTTPS destination. HSTS can avoid this unencrypted first step for a host already covered by a policy. A dynamic header does not retroactively protect an initial HTTP request when the policy is still unknown. Conversely, missing HSTS does not prove that a modern browser actually uses HTTP; direct HTTPS requests and browser-side HTTPS upgrades also play a part. RFC 6797, section 14.6, HSTS Preload: context
Three questions are central to deployment:
- Do HTTPS and certificate renewal work reliably for the host covered?
- Which additional subdomains would
includeSubDomainscover? - Can you sustain the chosen storage duration and, if relevant, a preload entry over the long term?
What HSTS does against SSL stripping
In SSL stripping, an attacker on the network path exploits an unprotected initial HTTP connection. They can manipulate redirects or links and keep the browser on HTTP while using HTTPS themselves to reach the actual server. This does not simply decrypt a TLS connection that has already been correctly established and validated.
On narrow screens, scroll the table sideways.
| Situation | Possible sequence | Limit of the conclusion |
|---|---|---|
| HTTP request without an effective HSTS policy or another HTTPS upgrade | The first request may start unencrypted. An attacker on the network path can manipulate this initial connection; data sent over HTTP may be exposed. | Missing HSTS alone establishes neither a successful attack nor that the browser used HTTP. |
| HTTP request with an effective HSTS policy | The browser uses HTTPS before accessing the network. There is no initial unencrypted HTTP connection to the covered host. | This browser must already know the policy. It does not protect against all network or application attacks. |
The first situation is the attack scenario this explanation addresses. Browser warnings, HTTPS upgrades and secure cookie attributes also affect which data is at risk in a particular case. HSTS replaces neither correct TLS configuration nor secure cookies or application protection. RFC 6797, threat model
The HSTS header in detail
The server sends the policy in the Strict-Transport-Security response header. A browser processes it only after receiving it over an error-free HTTPS connection. An HSTS header sent over unencrypted HTTP is ignored. RFC 6797, section 8.1
A short initial policy for this host, without extending it to subdomains or opting into preload:
Strict-Transport-Security: max-age=300This is an example header, not a complete server configuration. Choose an implementation guide for the specific layer that sends it.
On narrow screens, scroll the table sideways.
| Part | Meaning | Decision before use |
|---|---|---|
max-age=300 | The browser stores the policy for 300 seconds, or 5 minutes, from receipt. A later valid HSTS header updates the stored expiry time. | A short duration limits the commitment of a newly learnt policy. It does not automatically shorten older entries in browsers that have not yet received the new header. |
includeSubDomains | The policy also covers hosts beneath this host. For example.com, these include www.example.com and shop.example.com; for www.example.com, example.com is not included. | Identify affected subdomains, including nested and internally used web services, and check their HTTPS support. |
preload | An additional opt-in directive for the preload programme, not an HSTS directive defined in RFC 6797. | The header alone does not establish inclusion or distribution. Preload has further prerequisites and consequences. |
max-age is required; includeSubDomains and preload are not mandatory for ordinary HSTS use. Long values such as 31536000 (365 days) or 63072000 (730 days) belong at the end of a deliberate operational decision. They are not general starting values. RFC 6797, sections 6.1 and 8.1, preload requirements
Introduce HSTS gradually
First check HTTPS, certificates, redirects and your application's response paths. Make sure you can change the active configuration and renew certificates. Establish who will act if a failure occurs.
The following progression is a planning example. It specifies neither fixed project weeks, success criteria under load nor automatic approval. Check the affected web services at every stage and allow at least the current storage duration to pass before increasing it. HSTS Preload: deployment recommendations
On narrow screens, scroll the table sideways.
| Stage | Example value | What should be established before the next stage |
|---|---|---|
| Short functional test | max-age=300 | The header arrives over valid HTTPS. Important pages and required response paths work. |
| Observe in operation | max-age=604800 | A week's storage duration is acceptable; certificate renewal, error handling and responsibilities are clear. |
| Longer observation | max-age=2592000 | A 30-day storage duration suits the operation. Any problems encountered have been resolved. |
| Long-term policy | max-age=31536000 | The operator can provide HTTPS reliably throughout the long commitment. |
| Optional: include subdomains | Add includeSubDomains to the deliberately chosen value | All affected web services have been identified and support HTTPS. The extension itself is introduced deliberately. |
| Optional: preload | For example, max-age=63072000; includeSubDomains; preload | A separate preload decision, fulfilled submission requirements and long-term HTTPS operation. Not a mandatory final step. |
Preload as a separate long-term decision
A preload entry actually present in the browser being used can require HTTPS even before the first visit. Chrome maintains such a list; other browsers use lists derived from it. This does not guarantee that every entry has reached every browser at a particular time.
The operators of hstspreload.org recommend HSTS but do not recommend preload generally. Do not add preload casually from a copied configuration.
Anyone deliberately choosing to submit a domain must meet the current requirements:
- Provide a valid certificate.
- If port 80 is open, first redirect HTTP to HTTPS on the same host.
- Serve all affected subdomains over HTTPS, including nested and internal web services. This includes
wwwif a DNS record exists for it. - Send an HSTS header over HTTPS on the base domain with at least
max-age=31536000,includeSubDomainsandpreload. - If that HTTPS response redirects again, send the header on that redirect itself.
Submission and status checking are separate steps. The header shows an opt-in, but does not yet establish a distributed list entry. The requirements must continue to be met after inclusion. Preload requirements
What an HSTS finding shows
A current HTTPS response shows which header the host examined serves on that response path. If there is a redirect to another host, the header received there belongs to the destination host. The destination response cannot establish an HSTS header for the original host.
A particular browser's stored state, a parent host's policy and an existing preload entry are separate matters. A missing header does not remove a previously stored policy: it may remain effective until expiry. RFC 6797, sections 8.1 and 8.6
Therefore check host, protocol, response status and relevant paths together. The existing Nginx guide to setting and checking HSTS provides a practical starting point. If the header is notable, the finding may already be enough to raise a specific configuration question with the responsible operator.
Document HSTS: scope and limits
An HSTS header is an individual technical finding about HTTPS use in supporting browsers. Document the host checked, URL, measurement time, received header and limits of the check.
The finding does not establish that all connections or personal data are protected. It replaces neither a TLS audit nor an assessment of regulatory requirements. In particular, a present header or a score does not establish NIS2, GDPR or IT-Grundschutz compliance. This guide does not assess legal duties in individual countries.
Relevant guides and next steps
The Nginx guide shows how to set the header and perform basic checks. The preload section explains its scope and prerequisites.
The Web Security Check examines publicly reachable configuration characteristics and shows individual findings with measurement limits. Such a finding does not replace checking all hosts, paths or browser states. The web security overview places HSTS alongside other topics.
Frequently asked questions about HSTS
What is HSTS?
HSTS stands for HTTP Strict Transport Security. A supporting browser uses only HTTPS for a host covered by the policy. The browser must already know the policy from a valid HTTPS response, a parent host or a preload list.
Does HSTS protect against all man-in-the-middle attacks?
No. An effective HSTS policy prevents an unencrypted HTTP connection to the covered host. A dynamic header does not retroactively protect a first contact for which the policy is not yet known. HSTS does not protect against every network or application attack.
What happens if the certificate expires?
A browser applying HSTS to the host must terminate the connection on TLS errors and must not offer an ordinary exception. Reliable certificate renewal and operational monitoring therefore matter. Finding a header does not establish that these processes work. RFC 6797, section 8.4
Can I undo HSTS?
A max-age=0 received over valid HTTPS removes the dynamic entry for that host. A parent includeSubDomains policy or a preload entry may still apply. If the browser does not receive the change, a previously learnt policy remains effective until it expires.
What does includeSubDomains mean?
The directive extends the policy to hosts beneath this host. It does not apply upwards or sideways: a policy from www.example.com covers neither example.com nor shop.example.com. Enable this extension only after checking the affected web services.
Does HSTS prove NIS2 compliance?
No. The header documents a limited browser instruction to use HTTPS. It does not demonstrate fulfilment of regulatory requirements. This guide does not determine which legal duties apply to a particular entity.
Sources
- RFC 6797: HTTP Strict Transport Security, November 2012; especially sections 2.3, 6.1, 8.1–8.6, 11.4 and 14.6.
- HSTS Preload: introduction, submission requirements and removal, consulted on 12 September 2026; a changing browser programme, not a general recommendation to preload.
The examples explain the mechanism. They are not measurements of a customer's website.