← All articles
Security Headers 2026-01-18 · 6 min read

Content-Security-Policy: Your Strongest Defence Against XSS

Cross-site scripting (XSS) — injecting malicious JavaScript into a page — remains one of the most common web vulnerabilities. A Content-Security-Policy tells the browser exactly which sources of code are trusted, so injected scripts simply do not run.

A starter policy

default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

This allows resources only from your own origin and blocks plugins and framing. From there you add the specific third parties you genuinely use (analytics, fonts, ad networks).

Deploy without breaking things

  • Start with Content-Security-Policy-Report-Only so violations are reported but nothing is blocked.
  • Collect reports, identify legitimate sources, and add them explicitly.
  • Avoid unsafe-inline for scripts — use nonces or hashes instead.
  • Once clean, switch the header to enforcing mode.

CSP rewards patience: a tight, tested policy is worth far more than a permissive one rushed into production.

Put this into practice
Run a free, private scan — no login, nothing stored.
🛡 Web Scan 🔒 SSL/TLS 📬 MX & Email 🎣 URL Check

Related articles

Security Headers HTTP Security Headers Explained: HSTS, CSP, X-Frame-Options and More A handful of response headers stop entire classes of attack. Here is what each one does and the value to set.