Check your HSTS header setup

SiteCurl checks for the Strict-Transport-Security response header on your site. If the header is missing, it is flagged as a warning. If the header is present but the max-age value is too short, that is also flagged. A max-age of at least 6 months (15,768,000 seconds) is best.

HSTS works by telling browsers: 'from now on, always connect to this site over HTTPS, even if someone types http://.' Once a browser sees this header, it will refuse to use plain HTTP for the specified max-age period.

The check checks both the presence of the header and the max-age value. A header with max-age of 300 (five minutes) is almost useless because the protection expires quickly. SiteCurl flags short max-age values so you know to increase them.

Here is the problem HSTS solves. When a user types your URL or clicks a link, the browser may first try HTTP (not HTTPS). Your server then redirects to HTTPS. That redirect takes a fraction of a second, but during that brief moment, the connection is unencrypted. An attacker on the same network (a coffee shop, airport, or hotel Wi-Fi) can intercept that unencrypted request and redirect the user to a fake version of your site.

This is called an SSL stripping attack. The user thinks they are on your site, but they are on a copy controlled by the attacker. Everything they type (passwords, credit card numbers, personal details) goes to the wrong place.

HSTS prevents this by telling the browser to skip HTTP entirely. After the first successful HTTPS visit, the browser remembers the HSTS policy for the duration of max-age. Each future visit goes straight to HTTPS with no HTTP step in between. The attack window closes fully.

The HSTS preload list goes one step further. Browsers ship with a built-in list of domains that should always use HTTPS, even on the first visit. Submitting your domain to the preload list at hstspreload.org protects users who have never been to your site before.

Without HSTS, each first visit to your site on a new browser has a moment of weak spot. HTTPS redirects protect most of the time, but they leave a gap that attackers can exploit on public networks. HSTS closes that gap.

HSTS also prevents accidental HTTP access. If someone bookmarks or links to an HTTP version of your URL, the browser converts it to HTTPS on its own. No redirect needed, no HTTP request sent.

For sites that handle any form of sensitive data (login pages, payment flows, contact forms), HSTS is a baseline security measure. Enterprise buyers and security auditors look for it in detail. A missing HSTS header is an easy item to flag in a vendor security review.

SaaS products with login pages need HSTS the most. User login info sent over an intercepted HTTP connection are right away compromised. HSTS makes sure the login page is always accessed over HTTPS.

E-commerce sites handling payment info face similar risks. Even though the payment form itself may be on a third-party processor, the page that links to it needs HSTS to protect the session cookie.

Any site with a contact form, newsletter signup, or user account benefits from HSTS. The info may seem low-risk, but email addresses and names collected on an intercepted connection can be used for targeted phishing attacks.

Step 1: Check HTTPS works on all pages. Before turning on HSTS, make sure each page on your site loads right over HTTPS. HSTS forces all traffic to HTTPS, so any page that does not work over HTTPS will break once the header is set.

Step 2: Add the HSTS header. In Nginx, add add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; to your server block. In Apache, add Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" in your .htaccess or virtual host config. In Cloudflare, enable HSTS in the SSL/TLS settings.

Step 3: Set max-age to at least one year. Use 31536000 (one year) for the max-age value. Shorter values like 300 or 3600 expire quickly and leave gaps in protection. Once you confirm everything works, a full year is the standard recommendation.

Step 4: Add includeSubDomains. If you use subdomains (blog.yoursite.com, app.yoursite.com), add includeSubDomains to the HSTS header so they are also forced to HTTPS. Make sure all subdomains have valid SSL certs first.

Step 5: Consider HSTS preloading. Once your HSTS header has been working for a while with max-age of at least one year and includeSubDomains, you can submit your domain to hstspreload.org. This adds your site to the browser's built-in list so even the very first visit uses HTTPS.

Mistake 1. Setting max-age too short. A max-age of 300 (five minutes) means the HSTS protection expires almost right away. The browser goes back to trying HTTP on the next visit. Use at least 31536000 (one year).

Mistake 2. Turning on HSTS before fixing mixed content. If your pages still load images, scripts, or stylesheets over HTTP, HSTS will block those resources. Fix all mixed content references to HTTPS before enabling HSTS.

Mistake 3. Forgetting subdomains. Without includeSubDomains, only the main domain gets HSTS protection. Subdomains remain vulnerable to SSL stripping. Add includeSubDomains once all subdomains have valid certs.

Mistake 4. Enabling HSTS preloading too early. Once your domain is on the preload list, removing it is slow and difficult. Test with a standard HSTS header for at least a month before submitting to the preload list.

After adding the header, check it with curl -sI https://yoursite.com | grep -i strict. You should see Strict-Transport-Security: max-age=31536000 or a higher value in the output. If it is missing, the header was not applied right.

Run another SiteCurl scan to confirm the HSTS check passes. SiteCurl checks both the presence of the header and that the max-age is long enough. If your max-age is below 6 months, it will still flag a warning.

HSTS is a single response header that closes the gap between HTTP and HTTPS. It prevents SSL stripping attacks and makes sure each visit to your site uses a secure connection. Add the header, set max-age to one year, and include subdomains. It takes five minutes and protects each user from that point forward.