What is a Content Security Policy?
It's a one-line HTTP header that tells the browser exactly which scripts, styles and resources your page is allowed to load — everything else gets blocked. It's your main defence against cross-site scripting, and it's missing on 27 of the 28 real sites in our audit corpus. Check in 30 seconds: open your site, press F12 → the Network tab → reload → click the first request → look for Content-Security-Policy under Response Headers. Not there? Any injected script runs unchallenged.
The audit checks this on every page it crawls — up to 25 pages — and names every offender in the report.
The definition, in plain English
Content-Security-Policy: … — that instructs the browser to load scripts, styles, images and frames only from sources you explicitly allow. Its job is to make cross-site scripting (XSS) attacks fail: if an attacker manages to inject a malicious <script> into your page — through a form, a comment field, a compromised plugin — the browser refuses to execute it because it isn't on the allow-list. Without a CSP, the browser trusts everything the page contains, so one injection point anywhere on your site becomes a working attack on every visitor.
What our engine actually checks
Rule security/csp · severity: warning · flagged on 27 of the 28 real audits behind our statistics page
The audit checks every crawled page for a Content-Security-Policy response header and validates its directives when one exists. The common failure is simply its absence — no header at all — which the engine reports site-wide, since headers apply to every page equally. A present-but-hollow policy (one containing 'unsafe-inline' for scripts, which reopens the hole CSP exists to close) is also flagged.
In the corpus this ties for the most common finding: 27 of 28 sites had no CSP. That's typical — CSP is the security control almost nobody small sets, even though it costs one header.
Why it matters, honestly sized
No CSP doesn't mean you're being attacked today — it means that if an injection bug exists anywhere in your stack (a plugin, a form handler, a third-party widget), there is nothing standing between the injected script and your visitors. The realistic damages are the classic ones: stolen session cookies, defaced pages, injected spam links that get your site flagged, and skimmer scripts on checkout pages — the PCI council now expects card-handling sites to have a CSP for exactly that reason.
There's also a trust cost you can't see: security scanners, some enterprise procurement checklists and browser extensions flag sites without a CSP. It's one of the four security headers our audit treats as table stakes.
The fix, step by step
- Start in report-only mode. Serve
Content-Security-Policy-Report-Only: default-src 'self'first — the browser logs violations without blocking anything, so you discover what your site actually loads before enforcing anything. - Build the allow-list from what you see: your own domain plus the third parties you genuinely use (fonts, analytics, payment frames). Key directives:
default-src 'self', thenscript-src,style-src,img-src,frame-ancestors. - Avoid
'unsafe-inline'for scripts. It defeats the point. Move inline scripts to files, or use nonces/hashes if you can't. - Set the header at your host or CDN — Cloudflare, Netlify or nginx config — so it applies site-wide without touching page code.
- Enforce and watch. Flip from report-only to the real header, keep an eye on the console for a day, and loosen the policy only where the site genuinely breaks. Test purchases and forms specifically.
What the £7.99 report checks — and what it can't
Everything here that can be checked from outside your site is mechanical, and mechanical is checkable. Full disclosure: some of it isn't, and we say which. The report is the full 21-category audit — what it costs and how it compares to doing it yourself are on their own pages.
The mechanical half
Checked across up to 25 pages per audit, with every offending page named and the exact fix spelled out.
- presence of a Content-Security-Policy header on your site
- directive sanity when a policy exists — including the 'unsafe-inline' hollow-policy trap
- the neighbouring headers in the same pass: HSTS, X-Frame-Options and clickjacking protection
- mixed content: HTTP resources loaded on HTTPS pages
— Not ours to claim
What no report sold from outside your site can do:
- The report checks headers and flags weak policies — it doesn't design your site's specific allow-list for you, because that depends on which third-party scripts your stack loads. The fix list tells your developer (or host support chat) exactly what to set and how to roll it out safely.
Fair questions, straight answers
Is a CSP really necessary for a small business site?
Necessary is strong — plenty of small sites run for years without one and are never attacked. But it's the cheapest meaningful security control on the list: one header, no code changes, and it's the difference between an injection bug being a near-miss and being a breach. Our audit flags it as a warning rather than an error for exactly that reason: important, not urgent.
Will adding a CSP break my website?
A badly rolled-out one can — that's why the first step is always report-only mode, where the browser logs what would be blocked without blocking it. You enumerate what your site really loads, build the allow-list around it, then enforce. Sites that skip the report-only phase and paste a strict policy from a blog post are the ones that break their analytics and embeds.
What's the difference between CSP and HTTPS?
They defend different things. HTTPS encrypts the connection between the visitor and your server so nobody in the middle can read or alter traffic. CSP controls what the page itself is allowed to load once it arrives. You want both: HTTPS is the pipe, CSP is the bouncer inside the building.
Where do I set the header — code or hosting panel?
Hosting or CDN level, almost always. Cloudflare (Transform Rules / Workers), Netlify and Vercel have header config; Apache uses .htaccess, nginx uses add_header. Setting it there applies to every page including ones you didn't build, and survives CMS updates. Only touch templates directly if your host offers no header control.
See what an attacker sees on your site.
Enter your URL and pay securely — your report PDF lands in your inbox in ~30 minutes,
with CSP, HSTS, clickjacking protection and mixed content checked site-wide.