How to Audit Security Headers Before Launch
Security headers are not a full security review, but they are a fast way to catch missing browser hardening before a public launch.
Updated 2026-05-25
Use the related tools
Technical SEO Checks
Debug redirects, headers, security policies, metadata, robots.txt, and URL structure before launches or migrations.
Related guides
Baseline headers
Start with a practical baseline: HSTS for HTTPS sites, a scoped Content-Security-Policy, clickjacking protection, nosniff, a restrictive Referrer-Policy, and a deliberate Permissions-Policy.
CSP launch checklist
A useful CSP should restrict script, object, base, and frame behavior. Report-only mode is helpful for testing, but it does not enforce protections.
- Use default-src as a fallback.
- Avoid broad script-src wildcards.
- Set object-src to none when possible.
- Use frame-ancestors for clickjacking control.
Common false confidence
A header can be present but still weak. For example, a permissive CSP, missing HSTS subdomain policy, broad CORS wildcard, or deprecated disclosure header can still deserve a warning.
FAQ
Can a header audit replace a penetration test?
No. Header audits check browser-facing response policy only. They should sit alongside application testing, TLS review, dependency checks, and manual security review.
Should every site use the same CSP?
No. CSP should match the scripts, frames, APIs, and assets your site actually needs.