What is HSTS
HSTS tells browsers to refuse HTTP forever for your domain. HSTS is part of the browser-facing trust boundary. It shapes what the client is allowed to reveal, load, or trust before any backend incident response even starts.
If you are already working through Content Security Policy and SSL / TLS, this topic gives you the missing layer between the raw signal and the decision you have to make. For a live check, start with the CyberFurl security headers scan and then use the See the web security headers feature page to see where it fits in the wider CyberFurl workflow.
The header anatomy
HSTS is simple by design: a browser sees Strict-Transport-Security over HTTPS and remembers that the site should only be reached over HTTPS for a defined period. The power comes from that memory, not from the syntax alone.
includeSubDomains and the rollback risk
includeSubDomains is powerful because it extends the rule to the whole namespace, but that is also what makes rollback harder. If forgotten internal hosts or legacy subdomains still rely on HTTP, the breakage is not theoretical; the browser will enforce the remembered rule anyway.
HSTS Preload list (hstspreload.org)
Preload takes the idea one step further by baking the HTTPS-only expectation into browser lists before the first request even happens. That removes the first-visit downgrade window, but it also raises the cost of mistakes because the browser no longer needs to learn the rule from the site itself.
Removing yourself from preload (12 months+)
Undoing preload is intentionally slow and procedural because preload is meant to be a durable commitment. Teams should treat preload as something to earn after verifying the full subdomain surface, not as a cosmetic checkbox.
HowTo: deploy HSTS safely
A safe rollout starts with clean HTTPS everywhere, then a conservative max-age, then broader coverage such as includeSubDomains, and only then preload consideration. The main job is dependency discovery, not header typing.