How to Add Security Headers to Your Website
Updated 2026-06-21
To add security headers to your website, send a small set of HTTP response headers from your server or CDN: Content-Security-Policy (controls which scripts, styles and images can load), Strict-Transport-Security (forces HTTPS), X-Frame-Options (blocks clickjacking), X-Content-Type-Options (stops MIME sniffing) and Referrer-Policy. The fastest way to get the exact syntax right is to compose them in the CSP & Security Header Builder and paste the generated block into your server config.
The headers that matter most
You don't need dozens of headers — a strong baseline is five:
- Strict-Transport-Security — for example, a max-age of 31536000 (one year) with includeSubDomains tells browsers to always use HTTPS.
- X-Frame-Options: DENY — prevents your pages from being embedded in an attacker's iframe.
- X-Content-Type-Options: nosniff — forces browsers to respect the declared content type.
- Referrer-Policy: strict-origin-when-cross-origin — a sane default that stops leaking full URLs to other sites.
- Content-Security-Policy — the big one, covered below.
Permissions-Policy is a useful sixth if you want to switch off APIs like camera, microphone or geolocation.
Building a Content-Security-Policy without breaking your site
CSP is the most powerful header and the easiest to misconfigure. It works as a list of directives, each naming the sources a resource type may load from. A reasonable starting policy sets default-src to self, then opens up only what you actually use — for instance allowing styles from self plus a fonts host, and scripts from self plus your analytics domain.
The common pitfall: a too-strict policy silently blocks your own scripts and the page renders blank. Three tips:
- Start in report-only mode so violations are logged but nothing is blocked, then tighten.
- Avoid unsafe-inline for scripts where you can — use a nonce or hash instead.
- Remember that frame-ancestors in CSP supersedes X-Frame-Options in modern browsers, so set both for older clients.
In the builder you toggle each directive and source, watch the policy assemble live, and catch contradictions before they ever reach production.
Copy it into nginx, Apache or a meta tag
Once your headers look right, you need them in the correct format for your stack. The same policy is expressed differently depending on where it lives:
- nginx uses add_header directives inside a server or location block.
- Apache uses Header set lines in a .htaccess file or virtual host.
- A meta tag in your HTML head works for CSP when you can't change server config — though it can't deliver HSTS, which must be a real response header.
The CSP & Security Header Builder outputs all three so you copy the one that fits, paste it, and reload your server. After deploying, verify with your browser's network tab or a header scanner that each header is present on a live response.
Everything runs locally in your browser — you compose and copy the config without sending your domain, policy or any data to a server. Build your security headers now and ship a hardened site in minutes.