Security header monitoring

One request per run, and the response headers are read in full:

• HSTS — present, the max-age value, and whether includeSubDomains and preload are set.
• Content-Security-Policy — present, and whether unsafe-inline or unsafe-eval appear in the script sources. A policy with a default-src and no script-src is read correctly: scripts fall back to the default, and the check follows that fallback rather than reporting a missing directive.
• Frame protection — X-Frame-Options, or a CSP frame-ancestors directive, which supersedes it.
• X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
• Set-Cookie flags — Secure, HttpOnly and SameSite on every cookie the response sets.
• The http-to-https upgrade — whether the plain-http URL actually redirects.

Default interval

1 hour

Minimum interval

15 minutes

HSTS max-age floor

180 days

Checks https upgrade

Yes

Security headers are opinions as much as facts. Whether you want Permissions-Policy is a decision about your product; whether your CSP may contain unsafe-inline depends on what you shipped and when you can stop.

So the check separates the two. Everything is scored and reported. Only the headers you explicitly mark as required, or a score below a minimum you set, can fail the check and open an incident.

Out of the box nothing is required and the minimum score is zero, which means the check starts as a report. That is intentional. A monitor that arrives already paging you about a header you had decided not to set is a monitor you mute in the first week, and a muted monitor catches nothing.

Alongside the score, each run stores a snapshot of the security-relevant headers. When the next run differs, the change is reported as drift: which header, what it was, what it is now.

This is the case worth having the check for. A CSP that disappears during a framework upgrade breaks nothing visible. The site loads, the tests pass, nobody notices — until the header has been gone for six weeks. A run that suddenly reports Content-Security-Policy removed is the fastest signal you will get.

Like DNS drift, this fires once and the baseline advances, so an intentional header change does not leave you with an alert you can never clear. It shows as degraded rather than failed, and opens no incident.

Two different jobs. This check is a monitor: one ordinary request per hour, indistinguishable from a visitor, safe to run against production forever.

The exposure scan in the testing half deliberately requests paths that should not exist, looks like an attack in your access logs, and asks you to confirm you are authorised before it will run. Headers want watching continuously; probing wants doing deliberately.