HSTS test and preload list checker

Why test HSTS?

The HSTS header is one of the most effective HTTPS security controls, yet it's often misconfigured: max-age too short, includeSubDomains forgotten, or a domain eligible for the preload list but never submitted. Testing your configuration regularly helps spot these gaps before they get exploited.

Three main use cases:

• Pre-production security audit: validate that the HTTPS chain, the HTTP-to-HTTPS redirect, and the Strict-Transport-Security header are consistent before opening a new domain to the public.
• Preload list preparation: verify the four requirements (max-age greater than or equal to 31536000, includeSubDomains, preload, HTTP-to-HTTPS redirect) before submitting the domain to hstspreload.org.
• Post-migration verification: after an infrastructure change (move to Cloudflare, migration to a new Nginx cluster), confirm the HSTS header is still sent with the right directives on the apex and on subdomains.

How to use the HSTS test in 3 steps

Step 1: Enter the domain

Type the root domain without https:// or path (for example captaindns.com). The tool automatically targets the HTTPS version of the site and follows the initial redirect if there is one. Avoid subdomains for the first analysis, unless your goal is to check a specific service (for example api.captaindns.com).

Step 2: Run the HSTS test

Click Test. CaptainDNS performs three actions in parallel: query the Strict-Transport-Security header returned by the server, request Chrome's preload list to confirm status, and parse the max-age, includeSubDomains, and preload directives. The full result appears in under 3 seconds.

Step 3: Apply the recommendations

Read your grade (missing, weak, good, preload-ready, or preloaded) and the list of suggested fixes. Copy the Nginx, Apache, or Cloudflare snippet that fits your stack, deploy it, and rerun the test to confirm the upgrade. Iterate until you reach preloaded if the preload list is your goal.

What is HSTS?

HSTS (HTTP Strict Transport Security) is an HTTP response header standardized by RFC 6797 in 2012. When a browser receives this header over a valid HTTPS connection, it remembers the domain and refuses, for the defined duration, any cleartext connection to it. The http:// to https:// rewrite happens locally in the browser, before any network packet, which closes the interception window during the first redirect.

The header has three directives:

• max-age: duration in seconds during which the browser enforces HSTS. Recommended value for stable production: 31536000 (1 year). For the preload list: minimum 31536000.
• includeSubDomains: extends protection to all subdomains (www, api, mail, etc.). Mandatory for the preload list.
• preload: signals the owner's consent to submit the domain to Chrome's preload list. Without this directive, hstspreload.org rejects the submission.

Example of a complete header:

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

Without HSTS, a user who types captaindns.com in the address bar sends an HTTP request in cleartext first. An attacker on the same Wi-Fi network can intercept that request and serve a hijacked version of the site (SSL stripping attack). HSTS makes this attack impossible after the first legitimate visit, and the preload list makes it impossible from the very first visit for domains preloaded into the browser.

The 5 grades explained

CaptainDNS assigns a grade based on the directives detected and the preload status. Here's the grading scale:

The preload-ready grade does not mean the domain is in the preload list: it only means it meets the technical requirements to be submitted. The submission itself happens on hstspreload.org and inclusion in Chrome usually takes 6 to 12 weeks.

How to fix your HSTS configuration

Here are ready-to-paste snippets for the three most common platforms. All of them activate an HSTS that meets the preload list requirements.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

The always keyword ensures the header is sent even on error responses (4xx, 5xx). Without it, a 404 page would not carry the HSTS header.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Enable the module with a2enmod headers if it isn't already, then reload Apache.

Cloudflare Workers

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

On Cloudflare, you can also enable HSTS from the dashboard (SSL/TLS, Edge Certificates, HTTP Strict Transport Security) without deploying a Worker.

After every change, rerun the HSTS test to confirm the change took effect on the CDN or reverse proxy.

Submitting to the HSTS preload list

The preload list is a list of domains hard-coded into Chrome (and reused by Firefox, Safari, Edge, and Opera). Any domain in the list is treated as HTTPS-only by browsers from the very first visit, without even needing to receive the HSTS header beforehand.

To submit a domain on hstspreload.org, it must meet four conditions:

• max-age greater than or equal to 31536000 (1 year).
• includeSubDomains directive present in the header.
• preload directive present in the header.
• HTTP-to-HTTPS redirect active on the apex domain and all subdomains.

The certificate must also be valid (full chain, not self-signed, not expired). Once submission is accepted, inclusion in Chrome takes on average 6 to 12 weeks, the time it takes for the change to ship in a new stable version of the browser.

Warning about irreversibility. Removing a domain from the preload list is technically possible (removal form on hstspreload.org), but it takes several months and only applies to future versions of Chrome. Users on older versions will keep forcing HTTPS for years. Before submitting, verify that every production, staging, and internal admin subdomain is reachable over HTTPS, and that you have no plan to migrate to a different domain name in the short term.

Real-world use cases

Incident 1: weak grade after an ANSSI audit

Symptom: an ANSSI audit reports that captaindns.com does send an HSTS header, but that the max-age value (3600) is too low to provide real protection.

Diagnosis: the HSTS test confirms the presence of Strict-Transport-Security: max-age=3600. No includeSubDomains or preload directive. The grade assigned is weak.

Action: update the Nginx configuration to max-age=31536000; includeSubDomains; preload, after validating that all subdomains (api, mail, status) respond over HTTPS. Rerun the test: the grade moves up to preload-ready.

Incident 2: subdomain broken after enabling includeSubDomains

Symptom: after enabling includeSubDomains on captaindns.com, the internal tool metrics.captaindns.com becomes unreachable for the teams. "ERR_SSL_PROTOCOL_ERROR" in Chrome.

Diagnosis: the metrics subdomain only has an HTTP endpoint. The includeSubDomains directive, cached by team browsers, now forces HTTPS, but no certificate is served on this subdomain.

Action: urgently deploy a Let's Encrypt certificate on metrics, or temporarily remove the includeSubDomains directive and clear the local HSTS cache for the teams (chrome://net-internals/#hsts) while the subdomain is brought into compliance.

Incident 3: preload-ready domain never submitted

Symptom: during an internal security audit, the test reveals that captaindns.com has been preload-ready for over a year, but is not in Chrome's preload list. New visitors stay vulnerable to SSL stripping on the very first visit.

Diagnosis: the server configuration is correct (max-age=31536000, includeSubDomains, preload, HTTP-to-HTTPS redirect). The preload status returned by Chrome is "Not in preload list".

Action: submit the domain on hstspreload.org. Track the confirmation, then wait 6 to 12 weeks for propagation in the stable Chrome release. Document the decision and its irreversibility in the internal security register.

FAQ - Frequently asked questions

Q: What is HSTS?

A: HSTS (HTTP Strict Transport Security) is an HTTP response header defined by RFC 6797. It tells the browser to contact the domain only over HTTPS for the duration set by max-age. Once the header is cached, the browser rewrites any http:// request to https:// before sending it, which prevents downgrade and SSL stripping attacks on untrusted networks.

Q: Which max-age value should I choose for HSTS?

A: For a cautious production rollout, start with max-age=300 (5 minutes) to test without commitment. Once the HTTPS chain is validated, gradually raise it to 86400 (1 day) then 604800 (1 week). For the preload list, the minimum required value is 31536000 (1 year), which is also the recommended value for stable production. A higher value brings no additional gain.

Q: Is HSTS preload reversible?

A: Yes, but very slowly in practice. You can request removal via hstspreload.org, but the operation takes several months and only applies to future versions of Chrome. Users on older versions will keep forcing HTTPS for years. Before submitting a domain, make sure all resources, including internal subdomains, are reachable over HTTPS.

Q: Does HSTS work without HTTPS?

A: No. RFC 6797 requires browsers to ignore the Strict-Transport-Security header when it's received over HTTP. Only responses served over a valid TLS connection can activate HSTS in the browser. So you must first deploy a valid certificate (Let's Encrypt for example) and redirect all HTTP traffic to HTTPS before sending the header.

Q: HSTS vs. HTTPS redirect, what's the difference?

A: A 301 redirect from HTTP to HTTPS is executed by the server after the cleartext request has left the device. An attacker in a man-in-the-middle position can intercept that first request. HSTS solves this: after the first visit, the browser itself converts http:// to https:// before any network traffic. The redirect is still needed for the very first visit and for clients that have never received the header.

Q: Should I enable includeSubDomains?

A: Yes, as soon as all subdomains (www, api, mail, admin, intranet, etc.) are reachable over HTTPS. The includeSubDomains directive extends HSTS protection to the entire domain and is mandatory for the preload list. Before enabling it, audit every active subdomain: an internal subdomain still on HTTP (a monitoring tool for example) will become unreachable once browsers cache the header.

Related tools

The HSTS test pairs with other CaptainDNS tools to cover HTTP, DNS, and mail security:

Useful resources

• CaptainDNS complete HSTS and preload list guide (reference guide to enable Strict-Transport-Security step by step: directives, Nginx, Apache, Cloudflare, AWS, Caddy configs, preload submission)
• hstspreload.org (official submission form for Chrome's preload list)
• MDN: Strict-Transport-Security (reference documentation on the HSTS header and its directives)
• RFC 6797 (original HTTP Strict Transport Security specification)
• OWASP HSTS Cheat Sheet (HSTS deployment best practices)
• content-security-policy.com (practical guide to HSTS with configuration examples)