Security headers: four HTTP headers worth setting today

Some of the most effective security you can add to a website isn't code at all. It's a few HTTP response headers that tell the browser how to behave defensively. They guard against whole classes of common attacks, they don't change how your site looks or works, and most of them are a one-line config change. The catch is that they're invisible, so they're easy to never get around to.

Our check looks for four headers in particular: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and X-Frame-Options. Here's what each one buys you.

The four headers

X-Content-Type-Options: nosniff The easiest one. It stops browsers from "MIME sniffing," meaning guessing a file's type and potentially running something as a script that wasn't meant to be. The entire value is nosniff. There's no downside and no reason not to set it.

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN Prevents your pages from being embedded in an <iframe> on another site, which blocks "clickjacking," where an attacker overlays your page invisibly to trick users into clicking things. SAMEORIGIN lets you frame your own pages but no one else.

X-Frame-Options: SAMEORIGIN

Referrer-Policy Controls how much of the current URL is sent to other sites when a user clicks a link or loads a resource. A sensible default keeps you from leaking full URLs (which can contain sensitive paths or tokens) to third parties.

Referrer-Policy: strict-origin-when-cross-origin

Content-Security-Policy (CSP) The most powerful and the most involved. CSP tells the browser exactly which sources of scripts, styles, images, and other content are allowed to load, which is the strongest defense against cross-site scripting (XSS), the most common serious web vulnerability. A strict CSP means an injected <script> from an attacker simply won't run.

CSP is also the one to approach carefully, because a too-strict policy can block your own legitimate scripts. Start in report-only mode, see what it would block, then tighten:

Content-Security-Policy-Report-Only: default-src 'self'; ...

Once it's clean, switch -Report-Only off to enforce it.

Why bother

Real protection. These headers neutralize clickjacking, MIME confusion, referrer leakage, and (with CSP) a huge share of XSS attacks, all common, well-understood threats.
Trust and diligence. Security headers are a visible sign a site is maintained by people who care. Security scanners and savvy partners check for them.
Low effort, no UX cost. Three of the four are a single line each with no tuning. Even CSP, the involved one, is config rather than code.

They pair with HTTPS and HSTS. In fact HSTS is itself a security header, so once you're adding response headers, do the whole set in one pass.

How to add them

These are response headers, so you set them wherever responses are configured:

CDN (Cloudflare, etc.): often a dashboard panel or a transform rule. The easiest place, and it covers everything.
Web server (nginx, Apache, Caddy): a few add_header / header lines.
Platform host (Vercel, Netlify): a config file (vercel.json, _headers) where you declare them.

Set the three simple ones immediately. Plan a little time for CSP, using report-only mode first so you don't accidentally break your own scripts.

How to check them

Open your browser's dev tools, Network tab, click the document request, and read the response headers. Or use a scanner like Mozilla Observatory or securityheaders.com for a graded report. Our audit reports which of the four are present and which are missing, so you get a quick read without leaving the report.

Common mistakes

Skipping the three easy ones because CSP felt intimidating. Set nosniff, X-Frame-Options, and Referrer-Policy today; tackle CSP next.
Shipping a strict CSP cold and breaking your own scripts. Use report-only first.
Setting headers on the HTML page only, not on the assets and API responses that also benefit.
Assuming a plugin added them without verifying in the network tab.

FAQ

Which security header should I add first?

X-Content-Type-Options: nosniff and X-Frame-Options: SAMEORIGIN. Both are one line with no tuning and no downside. Then Referrer-Policy, then CSP.

Is Content-Security-Policy hard to set up?

It's the most involved of the four because it can block legitimate scripts if it's too strict. Start in report-only mode to see what it would block, refine, then enforce.

Do security headers help SEO?

Not as a direct ranking factor, but they protect users and signal a well-maintained site, and security scanners reward them. The reason to set them is safety.

Where do I configure these?

On whatever serves your responses: your CDN, web server, or host's config. A CDN is usually the simplest single place to cover the whole site.

Key Takeaways

Four response headers harden a site against common attacks: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and X-Frame-Options. They are configuration, not code, and don't change how the site looks.
X-Content-Type-Options: nosniff and X-Frame-Options: SAMEORIGIN are one line each with no tuning and no downside, blocking MIME sniffing and clickjacking respectively.
Content-Security-Policy is the strongest defense against cross-site scripting (XSS) because it restricts which sources of scripts, styles, and other content can load, so an injected attacker <script> won't run.
Roll out CSP in report-only mode first (Content-Security-Policy-Report-Only) to see what it would block, then enforce it, so you don't break your own scripts.
Set these headers wherever responses are configured (CDN, web server, or platform host), and verify them in the Network tab or with a scanner like Mozilla Observatory or securityheaders.com.

Want to see which security headers your site is missing? Run a free audit. We check for all four. More in the Technical explainers.