The security headers checklist we use on our own website

Prospective clients scan a security firm’s website before they talk to it. So do attackers. Headers are the cheapest hardening you can do, and they are visible to anyone who runs a scanner such as securityheaders.com or Mozilla Observatory.

Here is what we ship, and why.

The headers

On Cloudflare Pages, headers live in a _headers file at the root of the build output:

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  Content-Security-Policy: default-src 'self'; script-src 'self' https://challenges.cloudflare.com; frame-ancestors 'none'; object-src 'none'; base-uri 'self'; form-action 'self'
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Cross-Origin-Opener-Policy: same-origin

The CSP above is shortened for the example. Our full policy also allows Cloudflare Web Analytics and the scripts our contact form needs.

Header	What it stops
Strict-Transport-Security	Downgrade attacks to plain HTTP. Two years, plus preload for the browser preload list.
Content-Security-Policy	Injected scripts running on the page. Ours allows only scripts from our own origin and Cloudflare.
frame-ancestors 'none'	Clickjacking, by refusing to be framed. It replaces X-Frame-Options.
X-Content-Type-Options	Browsers guessing a file is a script when it is not.
Referrer-Policy	Full URLs, which may carry tokens, leaking to other sites.
Permissions-Policy	Embedded content asking for camera, microphone or location.

The part that makes CSP work

A strict script-src 'self' blocks inline <script> tags. Most site builders inline small scripts by default, so turning on CSP breaks the site. We keep every script in its own file, which means the policy needs no unsafe-inline and no hashes to maintain.

Check this before you deploy. Load each page with the browser console open and look for CSP violation errors.

Beyond headers

Headers are one layer. Prospects also look at:

• Email authentication. SPF, DKIM and DMARC on your domain. Aim for p=reject once reports show legitimate mail passes.
• DNSSEC and CAA records. Sign your zone and limit which certificate authorities may issue for your domain.
• security.txt. A file at /.well-known/security.txt that tells researchers how to report a vulnerability (RFC 9116).

None of this takes long. A security firm without it has a hard time asking clients to do better.