Which security headers matter most?

Content-Security-Policy and Strict-Transport-Security provide the most protection. X-Content-Type-Options, Referrer-Policy and Permissions-Policy are quick, low-risk additions.

Can security headers break my site?

A strict Content-Security-Policy can block legitimate third-party scripts, and HSTS makes HTTPS mandatory for the duration of max-age. Both risks are managed by staging: report-only for CSP, a short max-age for HSTS.

Website Securityintermediateexplainer

Security Headers Explained

What each HTTP security header protects against, sensible starting values, and the order to deploy them without breaking your site.

Cyber Security Space editorial desk · Published 6 Aug 2026 · Updated 24 Aug 2026 · 2 min read · Reviewed 24 Aug 2026

Short answer

HTTP security headers are response headers that instruct the browser to restrict risky behaviour: Content-Security-Policy limits which resources can load, Strict-Transport-Security forces HTTPS, X-Content-Type-Options stops MIME sniffing, Referrer-Policy limits URL leakage, and Permissions-Policy disables unused browser features.

Key takeaways

Headers reduce the impact of injection and misconfiguration; they do not prevent a compromise.
Content-Security-Policy delivers the most value and needs the most testing — deploy it in report-only mode first.
HSTS is effectively irreversible for the max-age you set, so start with a short window.
X-XSS-Protection is obsolete; do not add it to new configurations.

What each header does

Header	Protects against	Reasonable starting value
Content-Security-Policy	Injected scripts and unexpected resource loads	default-src 'self'; object-src 'none'; frame-ancestors 'self'
Strict-Transport-Security	Downgrade and cookie interception over HTTP	max-age=86400 initially, raised after verification
X-Content-Type-Options	MIME type sniffing	nosniff
Referrer-Policy	Leaking URLs and query strings	strict-origin-when-cross-origin
Permissions-Policy	Unnecessary browser feature access	camera=(), microphone=(), geolocation=()
X-Frame-Options	Clickjacking on older browsers	SAMEORIGIN (with CSP frame-ancestors)

How should you roll headers out?

STEP 01
Start with the safe set
Add X-Content-Type-Options, Referrer-Policy and Permissions-Policy. These rarely break anything.
STEP 02
Enable HSTS with a short max-age
Confirm every subdomain and asset works over HTTPS, then raise max-age. Only consider preload once you are certain.
STEP 03
Run CSP in report-only
Collect violation reports for a couple of weeks, fix the legitimate ones, then enforce.
STEP 04
Re-test after every deploy
New third-party scripts are the most common cause of a CSP that silently gets loosened.

Adding 'unsafe-inline' to script-src removes most of CSP's value. Use nonces or hashes instead.

What headers cannot do

Headers act in the browser. They will not stop server-side injection, credential theft, or a compromised plugin writing to your files. A perfect header grade on a hacked site is still a hacked site — which is why header checks belong alongside file, account and search-side checks rather than replacing them.

Frequently asked questions

Which security headers matter most?: Content-Security-Policy and Strict-Transport-Security provide the most protection. X-Content-Type-Options, Referrer-Policy and Permissions-Policy are quick, low-risk additions.
Can security headers break my site?: A strict Content-Security-Policy can block legitimate third-party scripts, and HSTS makes HTTPS mandatory for the duration of max-age. Both risks are managed by staging: report-only for CSP, a short max-age for HSTS.

Sources

HTTP headers reference — MDN Web DocsSupports: Header semantics and directive values.
HTTP Strict Transport Security Cheat Sheet — OWASPSupports: HSTS rollout guidance.