What we check/Security headersHD-01

Content-Security-Policy

CSP tells the browser which scripts, styles and frames your pages are allowed to load.

Area

Security headers

Check

HD-01

Included

Free in every scan

What we check

We read the Content-Security-Policy header from your homepage and parse its directives.

Why it matters

If an attacker gets a script onto your page — through a comment field, a compromised analytics vendor, a stale dependency — CSP is what stops the browser running it.

It is the difference between a cross-site scripting bug and a cross-site scripting incident.

It is also the header with the most leverage per line. A single default-src ‘self’ turns the whole class of injected external scripts into blocked requests, before any of them run.

How to fix it

1. 1

   Start in report-only mode so nothing breaks while you learn what your pages actually load.

2. 2

   Watch the reports for a week, then enforce.

3. 3

   default-src 'self' plus frame-ancestors 'none' covers most of the value.

4. 4

   Keep the report endpoint after you enforce. A policy that silently blocks something legitimate looks, to a visitor, exactly like a broken page.

Content-Security-Policy: default-src 'self'; frame-ancestors 'none'; base-uri 'self'

Common questions

Will a CSP break my site?

It can, which is why report-only mode exists. Deploy Content-Security-Policy-Report-Only first and read what it would have blocked.

What about unsafe-inline?

It permits inline scripts, which is most of what an injection attack wants. We note it rather than failing you for it — it is extremely common — but moving scripts into files or using a per-request nonce is the real fix.

Do I need one if my site is static?

A static site has less to inject into, but it still loads third-party scripts, and those are the ones you do not control.