HSTS tells a browser to use HTTPS for a host for a defined period after receiving the policy over a valid secure connection. It can prevent later attempts to downgrade that host to ordinary HTTP. The difficulty is operational: a long-lived policy can outlast the service configuration that originally made it safe.
Before increasing max-age or adding includeSubDomains, inventory the names and services affected. A forgotten HTTP-only subdomain can become unreachable for browsers that learned the parent policy. Preload adds another distribution and recovery timeline that must be understood before submission.
Read the policy as stored browser state
The HSTS policy analyzer reviews a pasted Strict-Transport-Security value. It identifies directives and common configuration concerns. It does not prove that a browser received the header over a valid HTTPS connection or that the host appears in a browser's preload list.
Strict-Transport-Security: max-age=300This short example establishes a five-minute policy when accepted in the appropriate context. The duration is counted from receipt. Repeated valid responses can refresh the stored expiry, so a policy's effect is not limited to five minutes after the server configuration was first deployed.
A header sent only over HTTP does not establish HSTS in the ordinary way. The browser must receive it through the trusted secure path required by the specification. Test the HTTPS response and redirect flow rather than checking only a configuration file.
Choose max-age with recovery in mind
A longer max-age provides a longer remembered HTTPS requirement, but it also extends the consequences of losing HTTPS service. Start with a controlled short duration, verify normal application flows and increase it as deployment confidence grows.
Check certificate renewal, load balancer configuration and error responses. A site can send the correct header on the homepage while a separate edge or application path omits it. More seriously, a future certificate failure can block access for HSTS clients rather than offering a normal bypass route.
Keep the policy value tied to an operational owner. If a different team controls certificates or subdomains, involve them before broadening the policy. HSTS is a browser behaviour commitment whose consequences can cross the boundaries of the team editing one response header.
| Decision | Prerequisite | Recovery consideration |
|---|---|---|
| Short max-age | Working HTTPS on the host | Observe behaviour before extending duration |
| Long max-age | Reliable renewal and deployment | Clients can retain policy for a long period |
| includeSubDomains | HTTPS coverage across affected descendants | A child cannot simply opt out of the parent's rule |
| Preload submission | Current preload requirements and domain-wide readiness | Removal depends on browser list updates |
| max-age=0 | Valid HTTPS response reaches the client | Does not instantly clear all stored or preloaded state |
Inventory descendants before includeSubDomains
List public applications, old campaign sites, customer subdomains, development endpoints and services run by third parties. DNS records alone may not reveal every operational dependency, so consult service owners and certificate inventories too.
For each affected web hostname, confirm HTTPS availability and certificate identity. A redirect from HTTP to HTTPS is useful only if the HTTPS endpoint actually works. A third-party service using your subdomain may need a custom certificate configured before the parent policy can cover it safely.
A child host's max-age=0 does not override a still-applicable parent's includeSubDomains policy. That makes the inventory important: there is no simple per-child exception header that cancels the parent's requirement. Change the parent policy and distribution state according to the actual situation.
Handle a forgotten legacy subdomain
Suppose example.com enables includeSubDomains while archive.example.com still serves only HTTP. Users whose browsers learned the parent policy now attempt HTTPS for the archive and fail. Users with no stored policy may still reach it, creating an apparently inconsistent outage.
First restore a valid HTTPS service for the affected hostname if possible. That directly satisfies the learned requirement. Inspect certificate coverage, routing and the content served on the secure endpoint. Avoid telling users to clear browser state as the primary service repair.
If policy rollback is necessary, serve the intended corrective header over valid HTTPS and account for clients that have not returned to receive it. The previous max-age still matters. A server configuration change does not remotely edit every browser's stored policy immediately.
After recovery, add the missed hostname to the inventory and require an ownership check before future scope changes. The incident was not merely a header syntax problem; it exposed an incomplete map of services covered by the parent domain.
Treat preload as a separate commitment
Preload lists can ship HTTPS requirements with browsers, reducing reliance on a user's first successful secure visit. Writing the preload token in a response header is not the same as being accepted into and distributed through those lists.
Review the current submission requirements on the official preload service before proceeding. They can include redirect, duration and subdomain conditions. Validate all affected services and understand how future subdomains will inherit the commitment.
Removal is not immediate. It requires the relevant removal process and distribution through browser updates, and users may run older versions. Do not use preload as a casual experiment that you expect to reverse within minutes. Keep the domain capable of HTTPS throughout the recovery period.
Check the response that clients receive
Inspect redirects, successful pages, authentication responses and error paths at the public edge. A reverse proxy may add or replace headers, while an origin-only test sees a different configuration. Use the security header checker for its documented server-side perspective and confirm browser behaviour separately.
Watch for duplicate or malformed policy values introduced by several layers. A web server and CDN can both attempt to manage the header. Assign a clear owner and verify the final wire response rather than assuming both configurations combine as intended.
Keep development environments deliberate. A local test hostname under a production parent can inherit consequences from includeSubDomains. Use an appropriate development naming and HTTPS strategy instead of weakening production policy to accommodate an undocumented test service.
Connect HSTS readiness to certificate operations
Monitor certificate expiry and live deployment across the affected hosts. HSTS makes dependable HTTPS more important, so a renewal process that occasionally requires manual intervention should be repaired before a broad long-duration rollout.
Test recovery from a failed certificate deployment in a controlled environment. Know which team can restore the chain, reload the edge and verify the presented certificate. A documented policy value is not enough if nobody can repair the secure endpoint during an incident.
Record the final scope, max-age, rollout dates and preload status separately. This gives future maintainers a clear starting point when moving a domain, retiring a service or changing hosting providers.
Use two browser states in the rollout test
Test with a fresh profile and a profile that has already received the policy. The fresh profile helps inspect the initial navigation path, while the learned profile demonstrates the remembered HTTPS requirement. Record whether the domain is preloaded, because that changes the fresh-profile assumption. Use a controlled hostname for failure experiments and keep production service available. Comparing these states explains why a simple HTTP redirect test does not cover the same behaviour as a browser returning with stored HSTS policy. It also gives support a concrete reproduction for visit-history differences.
Frequently asked questions
Does an HTTP redirect provide the same protection?
A redirect is a server response after an HTTP request reaches the network. Learned or preloaded HSTS can make the browser choose HTTPS before that ordinary HTTP exchange. Redirects remain useful, but they address a different point in the navigation path.
Can I undo HSTS with max-age=0?
A valid secure response can remove the relevant stored dynamic policy for clients that receive it, but parent policies and preload state can still apply. Clients that do not receive the correction retain their existing state until its rules change or expire. Plan recovery accordingly.
Does includeSubDomains cover future subdomains?
Its scope is based on descendant hostnames, not only the names that existed when the header was deployed. New services under the domain must be designed with HTTPS readiness in mind. Make that requirement part of subdomain provisioning.
Is the preload token enough to join the list?
No. Submission, validation and browser distribution are separate steps. Check the official service for current status and requirements. A parser can recognise the token but cannot prove that every browser already carries the domain's preload entry.
Can a child opt out of the parent policy?
A child cannot cancel an applicable parent includeSubDomains rule merely by sending its own zero max-age. Review the parent's state and provide working HTTPS for the child. This is why broad policy should follow a complete service inventory.
Why do only some users see the failure?
Browsers can have different learned policies, preload versions and visit histories. Compare those conditions alongside certificate and network evidence. The inconsistent audience can be a clue to stored HSTS state rather than proof that the server works correctly.
What is the final rollout check?
Verify valid HTTPS and intended headers across the scoped hosts, dependable renewal, successful application flows and documented recovery. Confirm preload status separately if used. The objective is a sustainable HTTPS requirement, not merely a syntactically valid header.