Securing Your Site: A Practical HSTS Preloading Guide for Cloudflare Users

I keep seeing developers implement HTTP Strict Transport Security (HSTS) headers directly in their application code. It shows up in old web.config files, or in modern .NET apps as middleware in Program.cs.

// A common sight in a .NET app's Program.cs
app.UseHsts();

It's well-intentioned, but HSTS is an infrastructure concern. It belongs at the edge, not inside application code. This post walks through configuring it properly with Cloudflare and then getting your site onto the HSTS preload list.

#What is HSTS and Why Does It Matter?

HTTP Strict Transport Security (HSTS) is a response header your server sends to tell browsers: only connect to this site over HTTPS, and remember that for the next X seconds.

Think of it like giving a friend your new contact details and saying "forget the old number, always use this one." Their phone doesn't even try the old one anymore. Same idea.

What this actually prevents is SSL stripping - a man-in-the-middle attack where someone intercepts your initial HTTP request and downgrades your connection before you ever get to HTTPS. With HSTS, the browser refuses to make that unencrypted request in the first place, so there's nothing to intercept.

#The Hidden Danger of Application-Level HSTS

A fair counter-argument is "defense-in-depth" - what if you switch hosting providers and forget to set it at the edge? Having it in the app feels like a safety net.

The problem is that in most modern hosting setups, application-level HSTS doesn't just fail silently. It causes infinite redirect loops.

The culprit is SSL offloading, which is how almost every container, load balancer, and reverse proxy works:

1. A user connects to your site via HTTPS.
2. The connection hits the edge (your proxy, load balancer, or container host). This layer decrypts the traffic.
3. The edge then forwards the request to your application over HTTP.

From the app's point of view, that forwarded request looks insecure. So .UseHsts() does exactly what it's supposed to and issues a redirect to the HTTPS URL. The browser follows it, the proxy decrypts it, forwards it to your app over HTTP, the app redirects again, and now you're looping forever.

This is not a theoretical edge case. It's a regular occurrence when running apps in Docker/Kubernetes, behind NGINX, or on cloud platforms that terminate SSL before traffic reaches your code.

Managing HSTS at the edge avoids all of this. Cloudflare handles the HTTPS termination and sends the header itself - your app never needs to be involved.

#Prerequisites: Don't skip this

Before enabling HSTS, make sure your setup is solid. Getting this wrong can lock visitors out of your site entirely.

• Your entire site must be served over HTTPS - no mixed content, no HTTP pages.
• You need a valid, non-expired SSL/TLS certificate.
• All HTTP traffic must redirect to HTTPS. In Cloudflare, "Always Use HTTPS" under SSL/TLS > Edge Certificates handles this.
• If you're planning to preload (which you should), every subdomain (www., api., blog., etc.) must also work over HTTPS.

A real warning: once a browser stores your HSTS policy, it will refuse all HTTP connections to your site for the entire max-age duration. If your certificate expires or HTTPS breaks, returning visitors won't be able to reach you at all until it's fixed. There's no quick undo.

#Part 1: Configuring HSTS in Cloudflare

The Cloudflare side of this is straightforward - no code changes needed.

1. Log in to your Cloudflare dashboard and select your domain.
2. Navigate to SSL/TLS > Edge Certificates.
3. Scroll down to the HTTP Strict Transport Security (HSTS) card and click Enable HSTS.
4. You'll be presented with the settings. Click "Next" and then carefully configure the policy.

Here's what each setting does:

• Max-Age: How long, in seconds, the browser caches the HSTS policy. Cloudflare shows 6 months as "Recommended", but you need at least 1 year (31536000 seconds) to qualify for preloading.
• Include subdomains: Extends the policy to all subdomains. Required for preloading, but only enable this if all your subdomains actually work over HTTPS.
• Preload: Adds the preload directive to the header, which signals your consent to be included in browser preload lists. Also required for preloading.
• No-Sniff: A bonus setting - Cloudflare adds X-Content-Type-Options: nosniff, which stops browsers from guessing content types and ignoring your declared one.

Set Max-Age to at least 1 year, turn on Include subdomains and Preload, then save.

#Part 2: Joining the HSTS preload list

With HSTS active in Cloudflare, returning visitors are protected. But someone hitting your site for the first time still makes that initial HTTP request before the browser knows to upgrade it.

The HSTS Preload List closes that gap. It's a list of domains hardcoded directly into Chrome, Firefox, Edge, and Safari. If your domain is on it, the browser forces HTTPS from the very first request, before any headers have been exchanged.

Here’s how to get on it:

1. Ensure you have configured HSTS in Cloudflare as described above (1-year max-age, include subdomains, and preload enabled).
2. Go to the official submission site: hstspreload.org.
3. Enter your domain name and click "Check HSTS status and eligibility".
4. The site will check your live headers. If everything is correct, you'll see a "Status: [your-domain] is eligible for preloading." message.
5. Follow the prompts to submit your domain to the list.

Inclusion isn't instant - it can take weeks or months to appear in new browser releases, so submit sooner rather than later.

#Verification: did it work?

Two quick ways to check.

1. Browser DevTools: Open the site, hit F12, go to the Network tab, and reload. Click the first request (the HTML document) and look at Response Headers. You should see:

   Response Headerscopy

   strict-transport-security: max-age=63072000; includeSubDomains; preload

2. Online tools: securityheaders.com will scan your domain and give you a full breakdown of your security headers, including HSTS.

#Conclusion

Putting HSTS at the Cloudflare level keeps your security policies out of application code, where they don't belong, and in the one place where they can actually be enforced consistently across all your apps.

Getting on the preload list is an extra step, but it's worth it. It means every connection to your site is protected from the very first request, not just after the browser has visited once and cached the header.