How to Monitor HSTS Header Regressions with a Web Cron Job

HTTP Strict Transport Security protects returning visitors from downgrade attacks by telling browsers to use HTTPS only. A certificate can remain valid and a site can still look healthy while the HSTS header disappears, loses important directives, or is served only on a subset of routes. A scheduled web cron check makes that invisible security regression measurable.

Why ordinary uptime checks miss HSTS failures

Most availability monitors stop after confirming a successful status code and acceptable response time. HSTS is response metadata, so a 200 page can pass while Strict-Transport-Security is missing. The header may be stripped by a CDN rule, omitted after a framework upgrade, or applied to the origin but not the public edge.

Monitor the public delivery path rather than an internal host. The request should reach the same hostname, redirects, proxy layer, and TLS endpoint used by visitors. This pairs naturally with scheduled API health checks and keeps security controls observable from outside the stack.

Define an explicit HSTS contract

A useful monitor compares the received header with a route-specific contract. For a mature HTTPS-only domain, the contract might require a sufficiently long max-age, the includeSubDomains directive, and optionally preload. Do not assume every environment should use the same settings: staging domains and shared subdomains may need different rules.

• Require exactly one valid HSTS header on the final HTTPS response.
• Parse max-age as an integer and enforce a minimum approved value.
• Check required directives case-insensitively and ignore harmless ordering differences.
• Fail if a redirect chain ends on HTTP or crosses to an unapproved hostname.
• Record the last known-good normalized policy for comparison.

Normalization prevents noisy alerts. Split directives on semicolons, trim whitespace, lowercase directive names, and compare parsed values instead of raw strings.

Probe representative production routes

Check more than the home page. Include a sign-in page, a static asset host if it has its own policy, an API response, and one route served through each major cache or proxy configuration. A single correct response does not prove the header is consistent across the application.

Follow redirects but capture every hop. HSTS is meaningful on HTTPS responses, while the initial HTTP request should redirect immediately to HTTPS. Alert on redirect loops, mixed hostnames, or unexpected ports. The broader principles in HTTP cache header monitoring are useful here because edge configuration often varies by route and cache state.

Build a safe scheduled checker

The checker should send a simple GET or HEAD request with a clear user agent, a short connection timeout, and a bounded total timeout. Read only the headers needed for the contract. Return structured output containing the URL, final status, normalized policy, observed max-age, missing directives, and check timestamp.

Do not store cookies, authorization headers, or response bodies containing private data. If authenticated coverage is necessary, use a narrowly scoped test account and a protected endpoint following the guidance for secure web cron endpoints.

Use retries without hiding persistent failures

Network errors and regional edge propagation can be transient. Retry timeouts once or twice with short exponential backoff, but do not retry a deterministic policy mismatch many times. The patterns in cron job retry strategies help separate transport instability from a real configuration regression.

When several regions are available, compare results. One region missing HSTS can indicate an incomplete CDN deployment even if other locations remain healthy. Alert after two consistent failures from the affected region, while a global missing header should trigger immediately.

Choose severity based on the change

• Critical: the header is absent on the primary domain or traffic remains on HTTP.
• High: max-age drops below the approved minimum or becomes zero.
• Medium: includeSubDomains or preload disappears unexpectedly.
• Low: formatting changes but the normalized policy remains equivalent.

An actionable alert identifies the route, previous and current normalized policies, affected region, first failure time, and recent deployment identifier. Keep diagnostics concise and redact request secrets.

Test the monitor before relying on it

1. Run against a known-good production-like response.
2. Remove the header and confirm an immediate failure.
3. Set max-age to zero and verify severity.
4. Change only directive order and confirm no alert.
5. Serve one route through a misconfigured proxy and confirm route-level detection.
6. Simulate a timeout and verify retries remain bounded.

Scheduler timestamps must also be trustworthy. Add server clock drift monitoring so incident timelines and last-known-good values remain accurate.

Monitor HSTS as part of a security baseline

HSTS works alongside TLS, certificate renewal, Content Security Policy, DNS security, and secure cookies. The related guide to Content Security Policy regression monitoring uses the same contract-based approach for a different browser security layer.

A small scheduled HSTS check closes a common observability gap. By parsing the header, validating meaningful directives, checking representative routes, and alerting on risk rather than formatting, teams can catch HTTPS downgrade regressions before users are exposed.