Your deploy dropped CSP — and nobody noticed until monitoring did

Published 2026-08-02 · ~5 min read

Content-Security-Policy is easy to lose in a reverse-proxy change, a new CDN layer, or a framework upgrade that stops emitting the header. The site still loads. Users do not open a ticket. Search rankings do not tank overnight. You only find out when something — a monitor, a CI gate, or a patient attacker — looks.

Why this failure mode is quiet

CSP does not keep the lights on. HTTPS still works. The padlock still shows. Functional tests and uptime pings stay green. That is exactly why header regressions need a separate signal — not another uptime check.

Catch it with continuous monitoring

HTTPS Checker monitoring re-checks your domain on a schedule and emails (or webhooks) when a security header appears, disappears, or becomes weak — for example HSTS with max-age=0, or a Referrer-Policy that still leaks the full URL. Certificate Transparency alerts on paid plans catch unexpected certs for the same domains.

Catch it before merge (CI policy)

For pull requests, fail closed on the public API — no bash grade parsing required:

curl -fsS "https://httpsornot.com/api/v1/check?domain=YOUR_HOST&headersMinGrade=B&requireHsts=true"

Policy failure returns HTTP 422, so curl -f fails the job. Use headersMinGrade for a headers-only gate (closest to the old SecurityHeaders.com API), or minGrade for the composite HTTPS grade — they are different scales. See the CI policy docs, methodology, and the SecurityHeaders.com API migration guide.

Accuracy when we cannot see the site

If a CDN challenge blocks our probe, we set botProtectionBlocked and withhold the grade — we do not invent “all headers missing.” With CI policy params, that becomes a 422 so pipelines do not treat a block page as a green check. Accuracy pledge.

Run a one-off check on the homepage, turn on monitoring, and put /api/v1/check in CI. Quiet regressions stay quiet only when nobody is looking.