HSTS (HTTP Strict Transport Security) tells browsers to always use HTTPS for your domain, but the first visit before HSTS is received is still vulnerable. HSTS preloading closes this gap by baking your domain into browsers themselves.
How Basic HSTS Works
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Once a browser receives this header, it enforces HTTPS for your domain for the specified duration — but this protection doesn't apply until after the very first successful HTTPS visit.
The Gap HSTS Preloading Closes
A user's absolute first visit to your domain (before ever receiving the HSTS header) could theoretically be intercepted over HTTP — preloading solves this by having browsers ship with a built-in list of HSTS-enforced domains, protecting even the very first visit.
Step 1 — Ensure HTTPS Is Fully and Correctly Deployed First
Before pursuing preloading, verify: HTTPS works on the root domain and all subdomains, HTTP fully redirects to HTTPS (see HTTP to HTTPS Redirect: Forcing SSL on Nginx & Apache), and no mixed content issues remain (see How to Fix Mixed Content Warnings After Enabling HTTPS).
Step 2 — Configure the Preload-Eligible HSTS Header
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;The preload directive and a max-age of at least one year (31536000 seconds) are required for preload list eligibility.
Step 3 — Verify includeSubDomains Genuinely Works for ALL Subdomains
This is the most consequential and irreversible-feeling requirement: every single subdomain must support HTTPS correctly, since preloading applies HSTS enforcement to all of them — a subdomain that can't yet support HTTPS will become inaccessible for preloaded users.
Step 4 — Submit to the HSTS Preload List
Search for "hstspreload.org" (the official Chromium-maintained preload list submission site) and submit your domain — it verifies your configuration meets requirements before accepting submission.
Understanding the Commitment You're Making
Once your domain is in browsers' preload lists (which ship with browser updates), removal is slow and cannot be instantly reversed if you later need to run part of your domain over HTTP — this is a genuinely significant, semi-permanent commitment; don't preload without confidence in long-term HTTPS-everywhere support.
Testing Before Submission
The preload submission site itself validates your configuration and reports specific issues if your setup doesn't yet qualify — address any flagged issues before actually submitting.
What Happens After Submission
Inclusion isn't instant — it takes time to propagate into actual browser releases, and different browsers may update their bundled lists on different schedules.
Should Every Site Pursue Preloading?
Preloading offers genuine security benefit but with real inflexibility as a trade-off — appropriate for sites with full confidence in permanent, complete HTTPS coverage across every subdomain; less appropriate for sites still evolving their HTTPS deployment or occasionally needing HTTP for specific subdomains.
Common Errors
Preload submission rejected — almost always due to an incomplete HSTS header (missing includeSubDomains or insufficient max-age), or a subdomain that doesn't correctly support HTTPS.
Continue Reading
- HTTP to HTTPS Redirect: Forcing SSL on Nginx & Apache
- How to Fix Mixed Content Warnings After Enabling HTTPS
- Understanding HTTP Security Headers (CSP, HSTS, X-Frame-Options)
Browse more articles in SSL/TLS & Certificates.
