Guide
Security Headers
Security headers are instructions your server sends to the browser before a page loads.
Why They Matter
The browser trusts these headers when it decides what a page can load, where it can be embedded, and how much information it can share.
Good headers reduce the damage from common browser attacks. They do not replace secure code, but they give every page a stronger baseline.
Headers Worth Checking First
Start with Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
These headers cover the most common browser-side protections and are useful for marketing sites, dashboards, APIs with browser traffic, and SaaS products.
Simple Examples
A login page should block framing, force HTTPS, and avoid leaking full referrer URLs.
A static marketing page may use a lighter policy, but it should still send nosniff, a referrer policy, and HTTPS enforcement.
Common questions
Do security headers make a site secure by themselves?
No. They reduce browser-side risk, but you still need secure application code, safe authentication, patched dependencies, and careful server configuration.
Can I add security headers on a CDN?
Yes. Many teams add them at the CDN or reverse proxy layer because it keeps the policy consistent across apps.
Which header should I fix first?
Start with HTTPS enforcement, clickjacking protection, and nosniff. Then work on a careful Content-Security-Policy.
Can headers break a website?
Yes. CSP and Permissions-Policy can block resources or features. Test in staging before enforcing strict values.
How often should I check headers?
Check after CDN changes, framework upgrades, hosting migrations, and major frontend releases.