Security headers are HTTP response headers a server sends to tell the browser which protective behaviours to apply to a page. They add defence in depth against attacks like cross-site scripting, clickjacking and downgrade to HTTP.
Why it matters
Browsers have many features that are safe to switch on but are not enabled by default for compatibility reasons. Headers are a cheap way to opt in, usually through server or CDN configuration without code changes. Commonly used ones include Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy.
Example
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=()
Each line enables one browser-side protection for the page.
Common mistakes
- Copying a strict Content Security Policy without testing, which breaks scripts and styles.
- Setting headers on the main page but not on error pages or other hosts.
- Assuming headers fix vulnerable code. They reduce impact, not root causes.
- Letting a CDN or proxy overwrite or drop them.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.