Headers

Content Security Policy: the header that stops most XSS attacks dead.

Published 2026-05-12 · Last updated 2026-05-12 · Vantyris editorial

What this means for your business

• Most small business sites have no CSP at all, which means the browser will load and execute anything the page references — including malicious scripts injected through a vulnerable form, a compromised CMS plugin, or a third-party widget that got hacked.
• A useful CSP doesn't have to be complicated. Even a basic policy that allows scripts only from your own domain stops the vast majority of XSS attacks.
• CSP is tricky to add to an existing site because the policy has to allow everything your site already uses. Browser DevTools shows you what's being blocked when you start in `report-only` mode, so you can fix the policy before enforcing it.

How to fix

Start with `Content-Security-Policy-Report-Only` (observe mode), watch the browser report violations for a week, fix the policy until clean, then switch to the enforcing `Content-Security-Policy` header.

1. Audit what your site already loads. Open your site in Chrome DevTools → Network. Note every domain your site fetches scripts, styles, fonts, images, and frames from. Common ones: Google Fonts, Stripe, your CDN, analytics, embedded YouTube.
2. Draft a basic policy. A reasonable starting point: `default-src 'self'; script-src 'self' https://js.stripe.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; form-action 'self'`. Adjust the third-party domains to match your stack.
3. Deploy in report-only mode first. Send the header as `Content-Security-Policy-Report-Only` (note the suffix). The browser logs violations to console but doesn't block anything. Run your site through normal use for a week and watch the console for `Refused to load` messages. Each one tells you a domain your policy missed.
4. Tighten the policy until clean. Add the missing domains to the relevant directive. Or — better — refactor the site to use fewer external services. Each `https://` allowance in your CSP is a tradeoff.
5. Switch to enforcing mode. Rename the header from `Content-Security-Policy-Report-Only` to `Content-Security-Policy`. Now the browser enforces.

Owner: Your developer or web host. · Time: 1-2 hours of audit + 1 week of observe-mode + 30 minutes to flip on.

Common gotchas

• `'unsafe-inline'` on `script-src` defeats most of CSP's value. Avoid it. If you need inline scripts (legacy CMS templates), use a nonce instead.
• `'unsafe-eval'` is needed by some older JS frameworks (Vue's runtime compiler, certain dev modes). Avoid in production.
• If your site embeds anything via `<iframe>` (YouTube, Stripe checkout, Calendly), those need `frame-src` allowances.
• Don't deploy a strict CSP without observe-mode first. You will break something you didn't know was there.

How to verify the fix

Run a Vantyris scan; it checks for the presence of CSP and flags the most common weaknesses (unsafe-inline, unsafe-eval, missing default-src). Or run your site through observatory.mozilla.org for a detailed CSP grade.

Cyber Essentials alignment

This finding informs the following UK NCSC Cyber Essentials control areas:

• A2. Secure configuration — devices and services hardened against the inherent default vulnerabilities.

Vantyris is not a CE certifying body. The mapping above is informational.

Common follow-up questions

References

• MDN: Content-Security-Policy MDN
• OWASP: CSP cheat sheet OWASP

Related explainers

• HSTS: the security header that locks HTTPS on for good.
• X-Frame-Options and frame-ancestors: the anti-clickjacking header.