Loading...
Loading...
HTTP Strict Transport Security (HSTS) acts as a "security seatbelt," forcing browsers to refuse all insecure HTTP connections to your domain for a set period.
Without HSTS, you are susceptible to "SSL Stripping." An attacker on a coffee shop Wi-Fi can transparently downgrade your users from HTTPS to HTTP, intercepting passwords and session cookies. HSTS prevents this by hard-coding the HTTPS requirement in the browser cache.
Pro Tip: Start with a short `max-age` (e.g., 300 seconds) to test. If you deploy a broken HTTPS config with `max-age=2years`, you will brick your site for all previous visitors until the cache expires. HSTS requires a valid certificate on the initial connection to be trusted.
HSTS is either present in the Strict-Transport-Security response header on HTTPS responses or it is not. Check the apex and every subdomain you care about - scanners only read what the server actually returns.
curl -sI https://yourdomain.com | grep -i strict-transport-securitycurl -sI https://www.yourdomain.com | grep -i strict-transport-securityhttps://hstspreload.org/?domain=yourdomain.comStart at 300 seconds (five minutes) and sit there for a day. Move to 86400 (one day) for a week. Then 31536000 (one year). Only set 63072000 (two years, the preload minimum) once you are confident the HTTPS config is stable across every endpoint.
No. HSTS via the header alone protects returning visitors. Preload submission protects the very first visit on a new device, which is the window where SSL stripping usually happens. Preload is strongly recommended but not required for the header to work.
Users see a browser error with no option to click through, because HSTS disables the usual "Proceed Anyway" link. This is by design. Set up certificate monitoring and renewal automation before enabling HSTS with a long max-age.
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.