What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
HTTP Strict Transport Security (HSTS) is a browser-enforced policy delivered in the Strict-Transport-Security HTTPS response header. Once a browser accepts it, the named host is accessed through HTTPS for the period set by max-age; later HTTP attempts are upgraded automatically, and the browser will not let a user bypass certificate warnings for that HSTS host.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Enable HSTS only after HTTPS works reliably on every hostname you plan to cover. Start with a short testing period on the main host, verify application and administrative traffic, then extend the duration, add includeSubDomains when every affected subdomain is ready, and consider preload only after accepting its difficult rollback path.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
How HSTS works
HSTS is not a redirect and it is not a setting that browsers learn from an insecure connection. Your HTTPS endpoint sends a response header such as:
Strict-Transport-Security: max-age=31536000The browser records a policy for that host. During the recorded period, a request typed as http://host is internally changed to HTTPS before the network request is made. This closes the initial opportunity for an attacker to interfere with an HTTP-to-HTTPS redirect.
#1 Best Overall
The policy belongs to a domain name. Browser handling also applies the HTTPS requirement across ports according to the browser’s HSTS rules, so moving an application to an unusual port does not automatically avoid the policy. HSTS affects future browser requests; it does not encrypt traffic from clients that do not implement HSTS, and it does not repair an endpoint whose TLS configuration is broken.
Why the HTTPS-only delivery rule matters
Browsers ignore Strict-Transport-Security when it arrives over plain HTTP. An attacker could otherwise inject a header on an untrusted connection and impose a policy of their choosing. The header must therefore be sent by the HTTPS response from the host that is establishing the policy.
What happens with certificate errors
On an HSTS host, the browser does not present the usual “continue anyway” bypass for a certificate warning. That behavior protects users from silently accepting a man-in-the-middle connection, but it also means an expired certificate, an incomplete chain, or a hostname mismatch can make the site unreachable until the TLS problem is fixed.
HSTS directives and choosing values
| Directive | Effect | Use it when |
|---|---|---|
max-age |
Sets how many seconds the browser remembers the host’s HTTPS-only policy. | Always; choose a short value for an initial test and increase it after the deployment proves stable. |
includeSubDomains |
Extends the policy to subdomains of the host. | Every covered subdomain, service, certificate and port is ready for HTTPS. |
preload |
Non-standard signal used when applying for inclusion in browser preload lists. | Only after meeting the current preload service requirements and accepting a difficult reversal process. |
max-age is measured in seconds
A one-year value is 31536000 seconds. A commonly published preload-oriented example uses two years, 63072000 seconds:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadThe two-year number is an OWASP guidance example, not a requirement for ordinary HSTS. Use a duration that matches your ability to maintain certificates, redirects and every service covered by the policy.
When to add includeSubDomains
Without this directive, the header applies to the host that sent it. With it, browsers also enforce HTTPS for subdomains. That can include forgotten administration names, legacy APIs, staging systems, mail-related web services, tenant-specific names, or third-party services delegated beneath the same parent domain. Add it only after an inventory confirms that each affected name has working HTTPS and a certificate valid for that name.
What preload changes
preload is not what turns on ordinary HSTS. It is a signal associated with applying for browser preload-list inclusion. MDN’s documented requirements include at least 31536000 seconds of max-age and includeSubDomains. A preloaded domain can be upgraded to HTTPS before a browser has ever visited it and received a live header. That makes the protection stronger against a first-visit downgrade, but it also creates a durable operational commitment: removing the header does not instantly remove every browser’s preloaded entry.
Prerequisites before sending the header
HSTS should be the final enforcement step in an already reliable HTTPS deployment. Check these conditions first:
- Canonical HTTPS works: the main site loads over HTTPS without mixed-content failures or application features that still require HTTP.
- Certificates are valid: names match, certificates are current, and the complete chain is served. Renewal must be automated or operationally monitored.
- Redirects are intentional: HTTP can redirect to the canonical HTTPS URL, while HTTPS-to-HTTP redirects are removed from normal flows.
- All assets and dependencies are ready: scripts, images, API calls, authentication callbacks and embedded services use HTTPS-compatible URLs.
- Hostnames are inventoried: list the main host and every subdomain that could be covered later. Include administrative and less frequently used names.
- TLS termination is understood: identify whether the application, web server, load balancer or reverse proxy terminates TLS, because that component must add the response header.
- Non-standard ports are tested: verify every HTTPS port used by the application and confirm that certificates and routing work there.
Do not add includeSubDomains merely because it looks more secure. Its scope is a production dependency decision, not a cosmetic header change.
A safe, staged enablement procedure
1. Make the canonical host completely usable over HTTPS
Open the site through its final HTTPS hostname and exercise the actions users depend on: sign-in, account recovery, checkout or other transactions, uploads, downloads, API calls, administrative consoles and redirects. Check from more than one network path if your architecture uses a CDN, proxy or regional load balancer. Correct certificate-chain, hostname and mixed-content problems before proceeding.
2. Add a short-lived policy to HTTPS responses only
Configure the component that terminates TLS to emit a header on the HTTPS responses for the target host. During an initial test, use a short max-age and omit includeSubDomains:
Strict-Transport-Security: max-age=300The exact configuration syntax depends on the platform. The implementation requirement is constant: an actual HTTPS response must contain the header. A setting applied only to an HTTP virtual host, or added before a proxy where it is stripped, will not establish the policy in browsers.
3. Test normal and exceptional paths
Use a browser that has received the test header and inspect:
- the canonical homepage and deep links;
- login, logout, password-reset and administrator paths;
- API endpoints and background requests;
- HTTP-to-HTTPS redirects;
- alternate HTTPS ports;
- certificate renewal and failover endpoints;
- every hostname you may later place under
includeSubDomains.
For a command-line check, inspect the real HTTPS response rather than an application configuration file:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallcurl -sSI https://HOSTNAMEReplace HOSTNAME with the host you are testing. Confirm that the returned headers include exactly the directives you intended and that an intermediary has not removed or altered them. Browser developer tools provide the same evidence in the Network panel when you select an HTTPS document response.
4. Increase max-age after the test is stable
Once the short policy has survived normal use and operational testing, raise the duration to a longer value appropriate for your maintenance process. A one-year value is:
Strict-Transport-Security: max-age=31536000Because the value is in seconds, document the chosen duration in deployment records and make certificate and redirect checks part of every release or infrastructure change.
5. Add includeSubDomains only after a complete inventory
When every intended subdomain supports HTTPS, change the header to:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Strict-Transport-Security: max-age=31536000; includeSubDomainsRe-test each covered name from a clean browser profile or another browser that has not retained an older policy. Pay particular attention to names that are rarely visited; a dormant service can still become unavailable to users as soon as the parent policy covers it.
6. Decide separately whether to request preload inclusion
Preload is optional. Apply only after confirming the current preload service criteria, including at least one year of max-age, includeSubDomains, valid certificates and reliable HTTPS redirects. Owners should also have a documented plan for every subdomain and a clear understanding that removal can require changes to browser-maintained lists and cannot be treated as an immediate rollback.
Where to configure HSTS
The header can be generated by the application, web server, load balancer or reverse proxy. Choose the layer that consistently handles the HTTPS response for every route, and ensure later layers do not overwrite it.
Rank #4
IIS
Microsoft documents HSTS as a site setting with a one-year (31536000) max-age and an option for includeSubDomains. Treat that option as a scope decision: enabling it affects subdomains, and the documentation cautions about its relationship to preload-list submission. After changing the site setting, inspect an actual HTTPS response to verify that the header is present.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Apache, Nginx, application frameworks and CDNs
These platforms expose equivalent response-header mechanisms, but directive names and placement differ by version and deployment mode. Follow the syntax documented for the component that terminates TLS. Make sure the rule applies to successful pages, redirects and error responses where your users might first encounter the host, and check whether a CDN or reverse proxy caches or removes security headers.
Do not assume that adding a rule to an origin is sufficient when a CDN serves the response. Test the public HTTPS endpoint, because that is what a browser receives and uses to establish HSTS.
Verification: prove the policy is active
Inspect the live HTTPS header
Check the public HTTPS URL with browser developer tools or an HTTP header command. Verify the spelling, capitalization-insensitive directive names, numeric max-age, and presence or absence of includeSubDomains and preload. Follow redirects and inspect the final response as well as the initial one; a redirecting endpoint that never sends the header may leave users dependent on a later page to establish policy.
Test browser behavior, not only server output
After a browser has received the header, enter an HTTP URL for the host. The browser should upgrade it to HTTPS without making an ordinary insecure request. Confirm that an invalid certificate cannot be bypassed through a “continue” option on the HSTS host. Use a separate browser profile for clean-state tests, because an existing policy can hide whether the current response is correctly configured.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsCheck the complete hostname and port set
Test the canonical host, every intended subdomain, redirects, alternate HTTPS ports and certificate-renewal paths. If you plan to use includeSubDomains, test names that are not part of the main application as well as production names. A successful homepage check alone does not establish that the entire covered estate is ready.
How to disable or roll back HSTS
To expire a host’s remembered policy, return this header over HTTPS:
Best Value
- Used Book in Good Condition
Strict-Transport-Security: max-age=0The zero value must come from a secure HTTPS response; sending it over HTTP cannot disable HSTS. Removing the header altogether is not an immediate rollback. A browser that already stored the policy continues enforcing it until the remembered duration expires.
Subdomain policies can be stored independently. Expiring the parent host does not necessarily erase a policy that a subdomain established for itself, and a parent policy with includeSubDomains can continue to affect names while it remains active. Roll back in the same scope in which policies were created, and keep HTTPS available while doing so.
Recommended Free Tools
Preload introduces an additional limitation. If the domain is in a browser preload list, serving max-age=0 does not instantly remove the preloaded entry. Follow the relevant preload service’s removal process and maintain working HTTPS until clients have updated their lists.
HSTS rollout options compared
| Rollout | Host scope | Remembered duration | Preload commitment | Readiness required | Rollback difficulty |
|---|---|---|---|---|---|
| Initial test | Single host | Short, such as 300 seconds |
None | Canonical HTTPS and tested routes | Low; wait for the short policy to expire or send max-age=0 over HTTPS |
| Established host policy | Single host | 31536000 seconds is one year |
None | Stable certificates, redirects, application paths and operations | Requires continued HTTPS until stored policies expire |
| Subdomain policy | Host and subdomains | Typically the chosen long duration | Optional | Every covered subdomain is HTTPS-ready | Parent and independently stored subdomain policies must be considered |
| Preload-oriented policy | Host and subdomains | At least 31536000 seconds under MDN’s documented requirements; OWASP shows 63072000 seconds as a common example |
Yes | Preload criteria, certificates, redirects and all subdomains verified | Highest; browser preload lists can enforce HTTPS before a live header is received |
Common failure modes and fixes
The header appears on HTTP but HSTS is not active
This is expected browser behavior. HSTS headers delivered over insecure HTTP are ignored. Configure the HTTPS endpoint and verify the public secure response.
A certificate warning locks out users
HSTS deliberately removes the bypass. Renew or replace the certificate, correct the hostname coverage, and serve the complete certificate chain. Do not treat an HSTS rollback as a substitute for repairing TLS; users may still have an active policy.
A subdomain breaks after adding includeSubDomains
Find the uncovered name, give it a valid HTTPS service, or remove the directive through a secure response while policies are still active. Check dormant, administrative and delegated names rather than limiting the investigation to the main application.
The policy seems absent after removing the header
Stored policies persist until their max-age expires. Return max-age=0 over HTTPS for the host, account for separate subdomain policies, and remember that preloaded domains need an additional removal process.
A proxy or CDN sends inconsistent values
Inspect the response visible from the public HTTPS address at multiple routes and through each delivery path. Configure one authoritative layer, prevent intermediaries from stripping the header, and avoid conflicting values between origin and edge unless the resulting behavior is deliberate.
An alternate port or API is unreachable
HSTS is associated with the host and browser port handling still applies. Verify that the alternate HTTPS port has correct routing, a valid certificate and an application that is prepared for HTTPS before enforcing a broad policy.
Operational checklist
- HTTPS works on the canonical host with valid certificates and complete chains.
- HTTP redirects are intentional and no required workflow depends on HTTP.
- The TLS-terminating component is identified and emits the header on the public HTTPS response.
- Initial testing uses a short
max-agewithoutincludeSubDomains. - Normal, administrative, API, redirect, alternate-port and renewal paths have been exercised.
- Every subdomain is inventoried before adding
includeSubDomains. - The selected duration is documented and supported by certificate and redirect monitoring.
- Preload is considered only after its one-year minimum, subdomain coverage and long rollback commitment are accepted.
- Rollback instructions use
max-age=0over HTTPS and account for independently stored subdomain policies.
Why the standard still matters
HSTS was standardized as RFC 6797, published by the IETF in November 2012. Its central idea remains straightforward: let a browser remember that a host must use HTTPS, so future navigation cannot be downgraded merely because a user entered an HTTP URL. The security benefit depends on disciplined deployment. A short, tested rollout protects the intended host without unexpectedly disabling forgotten services; a broad policy and preload can provide stronger first-visit protection only when the entire hostname estate can sustain HTTPS indefinitely.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
