How to Configure Strict Transport Security (HSTS) Preload in Google Chrome

Man-in-the-middle attacks, SSL stripping, and cookie interception often exploit the brief window when a user types a bare domain name (e.g., digitash.com) into the address bar, causing the browser to issue an initial unencrypted HTTP request before redirecting to HTTPS. HTTP Strict Transport Security (HSTS) with the preload directive permanently closes this vulnerability. When a domain is accepted into Google Chrome’s global HSTS Preload list, the browser hardcodes HTTPS enforcement directly into Chromium binary builds, ensuring unencrypted HTTP packets are never dispatched.

Understanding HSTS Header Directives and the Preload List

Enforcing HSTS across modern browsers requires configuring RFC 6797 response headers with specific strict directives:

• max-age=<seconds>: Defines how long the browser must cache the requirement that all traffic to the host occur strictly over HTTPS (typically 1–2 years: 31536000 or 63072000 seconds).
• includeSubDomains: Mandates that all present and future subdomains (e.g., api.digitash.com, dev.digitash.com) enforce HTTPS without exception.
• preload: Signals explicit domain-owner consent for submission into Google’s global HSTS Preload registry, which is hardcoded into Chrome, Firefox, Safari, and Edge.

Configuring the HSTS Preload Header on Web Servers

Deploy the compliant HSTS header on your origin web server or reverse proxy:

# Nginx configuration snippet
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Apache HTTP Server (.htaccess / httpd.conf)
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Ensure that your apex root domain issues an immediate 301 or 308 permanent redirect from HTTP to HTTPS before submitting to the preload list.

Inspecting and Querying HSTS Cache via chrome://net-internals

Chrome provides built-in internal networking tools to inspect live HSTS cache states:

1. Open Google Chrome, type chrome://net-internals/#hsts into the address bar, and press Enter.
2. Scroll down to the Query HSTS/PKP domain section.
3. Enter your target domain name (e.g., digitash.com) into the input box and click Query.
4. Examine the diagnostic readout:
   • static_sts_observed: Returns true if the domain is preloaded into Chrome’s hardcoded binary table.
   • dynamic_sts_observed: Returns true if Chrome received and cached the HSTS header dynamically during active browsing.
   • dynamic_sts_subdomains: Indicates whether subdomain inheritance is active.

Testing HSTS Header Delivery via Chrome DevTools

Verify that your origin server delivers compliant security headers:

1. Open Chrome DevTools by pressing Ctrl + Shift + I (or Option + Command + I on macOS).
2. Select the Network tab and check the Preserve log checkbox.
3. Navigate to your domain: locate the primary document request at the top of the waterfall.
4. Select the request and inspect the Headers panel:
   • Verify that Strict-Transport-Security appears under Response Headers.
   • Confirm that max-age is at least 31536000, and that both includeSubDomains and preload tokens are present.

Submitting Domains to the Official Chrome Preload Registry

Once compliant headers are verified across all subdomains:

1. Navigate to the official portal: https://hstspreload.org.
2. Enter your domain name to initiate the automated compliance scan.
3. Review the automated checks: valid HTTPS certificate, HTTP-to-HTTPS redirect, minimum max-age, and subdomain coverage.
4. Check the acknowledgment checkboxes and submit. Once accepted, your domain becomes permanently immune to SSL-stripping attacks across all major browsers.