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.
How to fix or implement HSTS
A good implementation plan for HSTS starts with inventory, not with copying a sample policy. Teams need to know which providers, applications, mail paths, or DNS owners are already in the flow before they tighten anything.
From there the safe pattern is consistent: publish the smallest defensible change, validate the result from the outside, and keep monitoring after rollout so the control does not quietly regress after a vendor or infrastructure change. CyberFurl helps most when that validation is tied back to live evidence from CyberFurl security headers scan.
- 1
Measure the live response surface
Capture the real headers, certificate chain, and browser-facing behavior that define HSTS in production. Development assumptions are not enough for internet-facing posture.
- 2
Tighten policy without breaking real traffic
Roll out the control in a staged way, especially if it changes browser execution, redirects, or certificate trust. The goal is durable enforcement, not a one-time header screenshot.
- 3
Validate in browser and scanners
Check the rendered application, network responses, and security tooling together so you can see whether HSTS is both technically present and operationally meaningful.
Tools to check your HSTS
Use the CyberFurl security headers scan when you want to see the live signal on a real domain, and then step back to the See the web security headers feature page when you need the wider workflow around posture, monitoring, or remediation. That combination is usually much more useful than reading the standard in isolation.
Further reading inside CyberFurl
- CyberFurl security headers scan
- See the web security headers feature
- Content Security Policy
- SSL / TLS
- CyberFurl public security report
Standards and references
Frequently asked questions
What's the recommended max-age?
The right next step is usually evidence first: inspect the live public behavior, identify the dependency or exposure that matters, and then decide whether to implement, tighten, monitor, or clean up. HSTS is most useful when the answer is anchored in what production is actually doing rather than in documentation alone.
Can HSTS break my site?
Yes, if the rollout is stricter than the real application path can tolerate. That is why the safer approach is to inventory dependencies first, roll out conservatively, and validate the user-facing behavior before tightening enforcement further.