How do I check whether a server sends a valid HSTS header?
HTTP Strict Transport Security tells supporting browsers to use HTTPS for a host after receiving a valid policy over a secure connection. Inspect the response actually delivered to clients, including any proxy or CDN layer. HSTS is a persistent browser policy, so changes need a working certificate and deliberate scope.
Before you start
- A functioning HTTPS hostname with a valid certificate.
- Access to the actual client-facing endpoint.
Instructions
1. Inspect HTTPS response headers
Check the real public endpoint, not only a backend behind a proxy. Review the Strict-Transport-Security header and any duplicate or conflicting copies.
curl.exe --head --connect-timeout 5 --max-time 15 https://app.example.com/Displays headers in Windows PowerShell while validating the HTTPS certificate.
2. Read the policy duration and scope
max-age is expressed in seconds. includeSubDomains extends the policy to descendant hostnames, which must also be ready for HTTPS. A header sent only over plain HTTP does not establish HSTS policy in a conforming browser.
3. Check operational readiness before changing it
Confirm certificate renewal, all affected subdomains and the service that injects the header. Increasing duration or including subdomains can make a certificate or legacy-host problem harder for clients to recover from. Browser preload submission is a separate decision, not a routine requirement.
Check the result
- The public HTTPS response has one intentional HSTS policy whose duration and subdomain scope match the service design.
Troubleshooting
- The browser upgrades HTTP but curl does not show an HSTS header
- The browser may have a cached or preloaded policy. Inspect the current public HTTPS response and historical deployment decisions before assuming the server is adding it now.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.