← Blog  ·  October 2026

Security Header Monitoring: Get Alerted When Headers Change or Disappear

Why security headers need continuous monitoring — and how to catch regressions the moment they happen, not weeks later.

Getting your security headers right is a one-afternoon project. You configure HSTS, add a Content Security Policy, set X-Frame-Options and X-Content-Type-Options, and your scanner shows green across the board. Then three months later a deployment resets your nginx config, a CDN policy change overrides your response headers, or a framework upgrade changes the default middleware — and your headers silently disappear.

This is the part most security guides don't cover: headers need to be monitored continuously, not just configured once.

How security headers disappear in production

Security header regressions are almost never intentional. They happen as side effects of routine operations:

Deployment pipeline changes

A new Docker base image, an updated nginx configuration template, or a framework upgrade can silently reset headers to defaults. If your security headers are set at the application layer, a deployment that reverts that configuration removes them. If they're at the server layer, any server reconfiguration risks losing them.

CDN reconfiguration

CDNs like Cloudflare, Fastly, and CloudFront can set, override, or strip response headers. A CDN configuration change — moving to a different cache tier, changing an edge rule, updating a WAF policy — can remove headers that were previously being injected at the CDN layer. Worse, CDN headers and origin headers can interact unexpectedly when both try to set the same header.

Infrastructure migrations

Migrating from one hosting provider to another, from EC2 to containers, from containers to serverless — the security headers were configured on the old infrastructure and need to be explicitly re-configured on the new one. This is frequently missed.

Multi-subdomain environments

Your main domain might have a hardened security configuration while subdomains (api.example.com, app.example.com, admin.example.com) have weaker or missing headers. A change to subdomain configuration that seemed unrelated can affect header presence.

What to monitor

The six headers with the most impact on your security posture:

• Strict-Transport-Security (HSTS) — enforces HTTPS. If this disappears, users can be redirected to HTTP during an attack.
• Content-Security-Policy (CSP) — primary XSS defense. The most complex header to configure and the most valuable to monitor because changes are often unintentional.
• X-Frame-Options — prevents clickjacking. Simple to set, easy to lose in a config change.
• X-Content-Type-Options — prevents MIME sniffing attacks. One line, zero downside, surprisingly often missing after a migration.
• Referrer-Policy — controls information leakage via referrer headers to third-party resources.
• Permissions-Policy — limits access to browser APIs (camera, microphone, geolocation) for your page and embedded content.

For each header, you want to monitor both presence (is the header set at all?) and value (has the value weakened? a CSP that was restrictive but is now default-src * is almost worse than no CSP).

How to check your current headers

Using curl

# Check all response headers (look for security headers in output)
curl -I https://yoursite.com

# Check a specific header
curl -s -I https://yoursite.com | grep -i "strict-transport\|content-security\|x-frame\|x-content-type"

Using a browser

Open DevTools → Network → click your page's request → Headers tab → Response Headers. You can see all headers the server is returning.

Using a free tool

Setting up automated monitoring

Manual spot checks are useful for audits but don't catch regressions immediately. Automated monitoring runs on a schedule, compares your current headers to a known-good baseline, and alerts you when anything changes.

Option 1: Simple cron script

#!/bin/bash
# security-headers-check.sh — run daily via cron

SITE="https://yoursite.com"
ALERT_EMAIL="security@yourcompany.com"
REQUIRED_HEADERS=(
  "Strict-Transport-Security"
  "X-Frame-Options"
  "X-Content-Type-Options"
)

for HEADER in "${REQUIRED_HEADERS[@]}"; do
  VALUE=$(curl -sI "$SITE" | grep -i "^$HEADER:" | head -1)
  if [ -z "$VALUE" ]; then
    echo "MISSING: $HEADER not present on $SITE" | \
      mail -s "⚠️ Security header missing: $HEADER" "$ALERT_EMAIL"
  fi
done

This catches absent headers but not weakened values. For CSP monitoring, you'd need to store the expected value and diff against it.

Option 2: CI/CD integration

Add a security header check to your deployment pipeline — run after each deploy and fail the deploy if critical headers are missing:

# GitHub Actions step — add after deployment
- name: Check security headers
  run: |
    HSTS=$(curl -sI ${{ env.PRODUCTION_URL }} | grep -i "strict-transport-security")
    if [ -z "$HSTS" ]; then
      echo "ERROR: HSTS header missing after deployment"
      exit 1
    fi
    echo "HSTS present: $HSTS"

This catches regressions at deploy time but doesn't monitor for changes that happen outside deployments (CDN config changes, infrastructure incidents).

Option 3: Dedicated monitoring service

A dedicated service checks your headers on a schedule from external infrastructure and alerts you when any header changes value or disappears — regardless of whether it was caused by a deployment, CDN change, or anything else.

Advantages over the DIY approaches:

• Detects changes from any cause (not just deployments)
• No server or script maintenance
• Change history — see exactly what the header value was before and after
• Works for sites you don't deploy yourself (third-party services, acquired products)
• Multiple domains in one place

What good security header monitoring looks like

A mature security header monitoring setup has three components:

1. CI/CD gate — catch regressions at deploy time before they reach production
2. External monitoring — catch changes from CDN, infrastructure, and other non-deploy events
3. Periodic audit — review header values quarterly, not just presence; tighten CSP as your dependencies stabilize

The CI/CD gate catches most regressions. External monitoring catches the rest. A periodic audit ensures your headers are getting stricter over time, not just present.

← All articles  ·  HeaderGuard  ·  Free security headers checker