Security Header Audit Checklist

This is the working checklist for the Security Header Auditing & Compliance reference: a single page an engineer runs top-to-bottom against a live origin to confirm every response header is present, correctly valued, and emitted on error pages as well as on 200 OK. It exists because header policy decays. A header set that scored an A six months ago drifts as someone adds a location block that drops inherited headers, a CDN strips a directive, a framework upgrade changes a default, or an error page returns from a path that never sees the middleware. The audit below is the standing control against that drift — each row maps a header to its required value, the attack it stops, the exact command that proves it, and the deep-dive reference where the full directive grammar lives.

Threat Model & Why an Audit

A point-in-time configuration review proves nothing about production. Three failure classes account for nearly every regression an audit catches, and none of them announce themselves:

• Header drift. Configuration is edited far more often than it is re-audited. An add_header re-declared inside one Nginx location block silently drops every inherited header for that path; an Apache Header set without the always condition vanishes on the exact 5xx responses an attacker can induce. The header is still in the main config — it is just not on the response.
• Missing on error pages. Security headers are part of the response, not the route. A 404, a 500, a WAF challenge page, or a static maintenance page often bypasses the application middleware entirely. An attacker who can force an error onto a victim then gets an unprotected document: no Content-Security-Policy, no framing control, no Strict-Transport-Security. The always flag and its per-platform equivalents exist precisely to close this gap.
• Regressions. A framework bump flips a default, a new reverse proxy normalizes header casing or strips an “unknown” header, a marketing tag manager injects an inline script that your CSP was never updated to allow. Each is invisible until something breaks or an audit re-runs the assertions.

The audit treats every header as a control with a verifiable wire value. You do not trust the config file; you read the bytes off the response. The coverage you are actually checking is three-dimensional — present, correctly valued, and present on error responses — and a header that satisfies the first two but fails the third is still a finding.

The Checklist

Work this table top to bottom against the target origin. The Verify command column assumes you have set H=https://example.com in your shell; each command should print the expected value or nothing (a finding). The Deep dive column links to the reference with the full directive grammar, platform syntax, and rollback procedure for that header. Treat an empty result as a failed row, not a pass.

For every row that passes on the homepage, repeat the command against a 404 (curl -sI $H/this-path-does-not-exist) and, where you can induce one, a 5xx. A header that is present on 200 but absent on 404 is the single most common drift finding — the always flag covers it on Nginx and Apache, and the full per-platform syntax is in each linked reference. The implementation patterns for the whole set are consolidated in the Web Security Headers Fundamentals reference and applied per stack in the Server & Platform Implementation Guides.

Platform-Specific Implementation

Below is a known-good baseline for the full header set, ready to paste and then tighten. Emit headers at the edge or reverse proxy so they cover error pages and responses served while the application is down. The CSP shown is a starting skeleton — replace 'nonce-...' with a per-request nonce as described in Content Security Policy essentials before treating it as production-grade.

Nginx

server {
    listen 443 ssl;
    server_name example.com;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), interest-cohort=()" always;
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Cross-Origin-Resource-Policy "same-origin" always;

    # Strip fingerprinting banners
    server_tokens off;            # removes the nginx version from Server
    proxy_hide_header X-Powered-By;
    more_clear_headers "X-Powered-By";   # requires headers-more-nginx-module
}

The always flag is mandatory on every add_header: without it Nginx omits the header on 4xx/5xx responses, leaving exactly the error pages an attacker can induce unprotected. The critical trap is inheritance — declaring any add_header inside a location block discards all headers inherited from server, so you must re-declare the full set in any location that adds its own. Detail in the Nginx security headers configuration reference. Verify: curl -sI https://example.com.

This inheritance rule is worth picturing, because it is the trap most audits fail to predict. Nginx add_header directives are not additive across contexts: a child context that declares even one add_header starts with an empty header table and inherits nothing from its parent. So a location that adds a single caching or CORS header silently strips the entire security set the server block declared — the config still reads correctly, but the response for that one path is naked. The figure below shows the same server block feeding two locations with opposite outcomes.

Apache

<VirtualHost *:443>
    ServerName example.com

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests"
    Header always set X-Frame-Options "DENY"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), interest-cohort=()"
    Header always set Cross-Origin-Opener-Policy "same-origin"
    Header always set Cross-Origin-Resource-Policy "same-origin"

    # Strip fingerprinting banners
    Header always unset X-Powered-By
    ServerTokens Prod          # Server: Apache (no version)
    ServerSignature Off
</VirtualHost>

always is the condition argument to set: it ensures the header is appended even on internally generated error documents, where the default onsuccess table skips them. Requires mod_headers (apachectl -M | grep headers). ServerTokens and ServerSignature belong in the main server config, not per-directory. Full patterns in the Apache .htaccess and VirtualHost hardening reference. Verify: curl -sI https://example.com.

Verification & Diagnostic Workflows

One command dumps every header for a fast visual pass — the same quick-check pattern used on the home page, widened to the full audit set:

curl -sI https://example.com | grep -iE 'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy|cross-origin-(opener|embedder|resource)-policy|cache-control|clear-site-data|x-powered-by|^server:'

Then confirm the headers survive an error response, because that is where drift lives:

curl -sI https://example.com/this-path-404s | grep -iE 'strict-transport-security|content-security-policy|x-frame-options'
# All three should still print. Empty output is a finding.

Validate the TLS chain before trusting Strict-Transport-Security — HSTS hard-fails on any certificate error, so a SAN gap on a subdomain is a lockout waiting to happen:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | grep -E 'Verify return code|subject='
# Verify return code: 0 (ok)

These commands are not four unrelated checks; they are an escalating pipeline in which each stage exposes a gap the previous stage is structurally blind to. The homepage dump proves presence and value on the happy path. The 404 re-run proves the always flag actually fired on a response the middleware never touched. The openssl step proves the transport HSTS depends on is sound before you trust a max-age you cannot easily revoke. Only then does an external grade mean anything — run it last, as a witness, not as the audit itself.

For a graded report and a second opinion, run the origin through an external scanner. The grade letters and what they reward (and the gaps they ignore) are explained in header grading with the Observatory and securityheaders, and the full local command toolkit — curl, openssl, and testssl.sh — is documented in auditing headers with curl, openssl, and testssl. Treat the external grade as a sanity check, not the source of truth: scanners test one URL, the audit table tests your error pages too.

Troubleshooting & Safe Rollback

• Header present on 200 but missing on 404/500 → the always flag (Nginx/Apache) or the framework’s error-handler path is dropping it. Re-emit at the edge so every response is covered.
• All server-level headers vanish under one path → an add_header (Nginx) inside that location discarded the inherited set. Re-declare the full block in the location, per the Nginx inheritance reference.
• Duplicate header (two values) → both the CDN/edge and the origin emit it. Browsers may honor the first or the strictest; remove one source so the wire value is unambiguous.
• Content-Security-Policy breaks the page after tightening → deploy it first as Content-Security-Policy-Report-Only, collect violations, then enforce. Reporting setup is in CSP violation reporting and monitoring. Rollback is non-destructive: switch back to report-only or relax the offending directive.
• HSTS lockout on a subdomain → a NET::ERR_CERT_* page with no proceed button means includeSubDomains is enforcing on a host whose certificate SAN does not cover it. Fix the certificate; you cannot click through. To unwind enforcement, serve Strict-Transport-Security: max-age=0 over HTTPS — but cached clients stay locked until their existing max-age lapses, so never preload coverage you cannot guarantee.
• Cross-Origin-Embedder-Policy: require-corp breaks third-party embeds → COEP demands every subresource carry CORP or CORS headers. Roll back by removing COEP first (it is the gating header), then re-introduce per debugging COEP-blocked resources.
• Clear-Site-Data logging users out unexpectedly → it was emitted on a path other than /logout. Scope it to the logout response only; it is destructive to client state by design.

Frequently Asked Questions

Which headers belong in a minimum baseline versus a hardened one? The minimum baseline that every site should pass is Strict-Transport-Security, Content-Security-Policy, a framing control (X-Frame-Options plus CSP frame-ancestors), X-Content-Type-Options: nosniff, and Referrer-Policy. A hardened profile adds Permissions-Policy, the Cross-Origin-* isolation trio, Cache-Control: no-store on sensitive responses, Clear-Site-Data at logout, and removal of X-Powered-By plus a minimized Server.

Why does the audit insist on checking error pages? Because security headers are a property of the response, not the route, and 404/500/maintenance responses frequently bypass the application middleware that sets them. An attacker who can force an error then receives an unprotected document. The always flag on Nginx and Apache is the fix; the audit re-runs each command against a 404 to prove it.

Is X-Frame-Options redundant now that CSP has frame-ancestors? Keep both. frame-ancestors is the modern, spec-driven control and takes precedence in browsers that support it, but X-Frame-Options: DENY still covers older engines and is cheap to send. Set them to equivalent policies so they cannot disagree.

Should I enable X-XSS-Protection? No. The legacy XSS auditor is deprecated, removed from modern browsers, and was itself a source of information-disclosure vulnerabilities. If the header appears at all, set it to 0. Real XSS defense is a strict Content-Security-Policy.

How often should this checklist run? On every deployment as an automated gate, and on a schedule against production. Drift is introduced by routine config and dependency changes, so a once-a-quarter manual review is not enough — wire the table’s assertions into CI as covered in automated header scanning in CI/CD.

Related

• Automated header scanning in CI/CD
• CSP violation reporting and monitoring
• Header grading with the Observatory and securityheaders
• Auditing headers with curl, openssl, and testssl
• Web Security Headers Fundamentals
• Server & Platform Implementation Guides