Why headers matter
Security headers tell browsers how to handle your pages. They can prevent MIME confusion, reduce clickjacking risk, and set stricter security policies for scripts and framing.
They are especially useful because they are easy to regress after server, CDN, or proxy changes.
The core headers to review
Different stacks need different policies, but a few headers are usually worth checking first.
- Strict-Transport-Security
- Content-Security-Policy
- X-Content-Type-Options
- X-Frame-Options
- Referrer-Policy
- Permissions-Policy
The biggest mistakes teams make
Some teams never add the headers. Others add them once and never validate them again. Another common issue is setting a header that is technically present but too weak to matter.
- Missing CSP or using an overly permissive one
- No HSTS on an HTTPS site
- Headers configured in one environment but not another
- Headers disappearing after infrastructure changes
How to approach implementation
Start with safe wins such as X-Content-Type-Options and Referrer-Policy. Then introduce stricter policies such as CSP with testing and reporting.
Document your expected headers so future deployments can be checked against a baseline.
- HSTS reviewed for secure environments
- CSP exists and is not excessively permissive
- X-Content-Type-Options is set to nosniff
- X-Frame-Options or CSP framing rules are present
- Referrer-Policy is defined intentionally
- Headers are checked after infrastructure changes