Copy · paste · reload

Security headers you can actually paste.

Copy-paste blocks for every HTTP security header — Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Permissions-Policy and more — for Nginx, Apache, Caddy and Cloudflare. One block per task, plus how to verify it.

15 recipes

Why this exists

The header is simple. The exact syntax for your server isn't.

You know you want Strict-Transport-Security or a sane Content-Security-Policy — but is it add_header with always, Header always set, a Caddyfile directive, or a _headers line? And why did your Nginx header vanish the moment you added another one? headerforge.pages.dev answers exactly that: one copy-paste block per header for every common server, the safe rollout for the risky ones (CSP), and the curl command to prove it's live.

How it works

Pick the header, copy your server's block, verify

  1. Pick a recipe. Browse by header or by server in the full recipe list.
  2. Copy the block for your stack. Each recipe has Nginx, Apache, Caddy and Cloudflare variants with one-click copy.
  3. Reload and verify. Every recipe ends with the curl -I command to confirm the header is being sent.

FAQ

Frequently asked questions

Are these header configs free?

Yes. Every recipe on headerforge.pages.dev is free to read and copy, with no account, paywall, or sign-up. Some outbound links (for example to hosting or CDN providers) may be affiliate links, which never change the price you pay.

Where do these headers go?

In your web server or platform config: an Nginx server block, an Apache .htaccess / vhost with mod_headers, a Caddyfile, a Cloudflare Worker, or a Cloudflare Pages / Netlify _headers file. Each recipe shows the exact block for every server, and there are per-server "all headers" pages too.

Will adding a Content-Security-Policy break my site?

It can if you go strict too fast. The CSP recipe shows you how to deploy Content-Security-Policy-Report-Only first, watch what it would block, then switch to the enforcing header once it is clean — so nothing breaks for users.

My Nginx add_header isn't working — why?

Nginx does not inherit add_header into a block that defines its own add_header directives, and headers on error responses need the "always" flag. This is the #1 reason headers silently disappear; the "common mistakes" recipe covers it with fixes.

How do I check which headers I'm actually sending?

Run "curl -I https://yourdomain" (or "curl -sI ... | grep -i <header>") to see the live response headers, or use a public scanner. Every recipe ends with the exact curl command to verify the header is present and correct.

Do I need all of these headers?

Start with the high-impact ones: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and X-Frame-Options. The "starter set" recipe gives you all the recommended headers in one copy-paste block per server.