HSTS Preloading

HSTS preloading is a one-way door. Walk through it and browsers enforce HTTPS forever—even for users who've never visited your site.

This solves a real problem. Standard HSTS only kicks in after someone visits your site over HTTPS and receives the header. But what about their very first visit? An attacker on the same network could intercept that initial HTTP request before HSTS ever had a chance to protect them.

Preloading eliminates this gap. But the cost is permanence.

How Preloading Works

Browsers ship with a hardcoded list of domains that must always use HTTPS. Chrome, Firefox, Safari, Edge—they all use the same list, maintained by the Chromium project. Your domain gets baked into the browser itself.

When a user types your domain, their browser doesn't ask your server what to do. It already knows: HTTPS only, no exceptions, no negotiation.

This happens before any network request. The protection is absolute.

The One-Way Door

Here's what makes preloading serious: removing your domain from the list takes 6-12 months. And even after removal is approved, users running older browsers will continue enforcing HTTPS for years.

If you preload on Monday and discover a problem on Tuesday, you cannot fix it quickly. There's no rollback. No emergency override. Browsers worldwide have your domain in their source code, and they won't check whether you've changed your mind.

This isn't a configuration change. It's closer to getting a tattoo.

Requirements

The preload list maintainers are strict because they know you can't easily undo this. Your domain must:

• Serve a valid, trusted HTTPS certificate
• Redirect all HTTP traffic to HTTPS
• Include the HSTS header on every HTTPS response
• Set max-age to at least one year (31536000 seconds)
• Include the includeSubDomains directive
• Include the preload directive
• Support HTTPS on every subdomain—including ones you haven't created yet

The header looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

The preload directive isn't part of the HSTS specification. It's a signal: "I understand what I'm asking for, and I want in."

The Subdomain Problem

The includeSubDomains requirement is where preloading claims its victims.

You preload example.com. Three months later, someone creates dev.example.com pointing to a staging server without a certificate. It's now inaccessible. Not broken—inaccessible. Browsers refuse to connect.

Or you have legacy.example.com running an old system that can't do HTTPS. Preloading just killed it.

Or api.example.com points to a third-party service that doesn't support HTTPS on custom domains. Gone.

Before you submit, you need to find every subdomain you've ever created. DNS enumeration tools help, but subdomains can hide. A forgotten CNAME from three years ago will surface the moment it becomes unreachable.

The Submission Process

Go to hstspreload.org. Enter your domain. The tool checks every requirement and shows exactly what's failing.

Fix the failures. Submit.

Your domain enters a queue. Within weeks, it's added to Chromium's source code. Chrome and Edge users get it first, within a few browser releases. Firefox and Safari sync their lists from Chromium, so they follow within months.

Full coverage—where essentially all users have browsers with your domain preloaded—takes about a year. But the most active users, the ones who keep their browsers updated, benefit within weeks.

Who Should Preload

Preload if you handle genuinely sensitive data: banking, healthcare, government. If an attacker intercepting a user's first visit could cause real harm, the permanence is worth it.

Preload if you've run standard HSTS for months without issues. If you haven't tested HSTS thoroughly, you're not ready to make it permanent.

Preload if you've audited every subdomain and can commit to HTTPS-only for all of them, forever.

Who Shouldn't Preload

Don't preload if any subdomain can't support HTTPS. The requirement is absolute.

Don't preload if you're still figuring out your infrastructure. Wait until things are stable.

Don't preload for the resume line or the security theater. The commitment is real, and the consequences of getting it wrong last for years.

Testing Before Commitment

Run standard HSTS first. Set a modest max-age—start with a week, increase to a month, then several months. Watch for problems.

Only after you've run HSTS for at least three months without incident should you add the preload directive and submit.

This isn't paranoia. It's respect for a one-way door.

Checking Your Status

After submission, hstspreload.org shows your domain's status in the queue. Once you're in the list, you can verify by trying to access your domain over HTTP in a fresh browser profile or incognito window. An updated browser will refuse the HTTP connection entirely.

Incognito mode is particularly useful for testing because it doesn't retain regular HSTS policies—only preloaded domains are enforced.