Content Security Policy is an HTTP header your web server sends to browsers. It tells the browser exactly which resources — scripts, stylesheets, images, fonts, iframes — are allowed to load on your page, and from where.

Without a CSP, a browser will load almost anything a page instructs it to.

The problem CSP solves

The main threat CSP defends against is cross-site scripting (XSS) — where an attacker injects malicious JavaScript into your page through a form input, a comment field, or a compromised third-party resource.

If injected JavaScript runs in a visitor's browser, it can steal session cookies, capture passwords and credit card numbers, redirect users, or silently load malicious content.

A properly configured CSP stops injected scripts from running even if the attacker successfully gets code into your page — the browser refuses to execute anything that doesn't match the policy.

What a CSP looks like

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.yourtrustedlibrary.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-ancestors 'none';
  • default-src 'self' — only load resources from your own domain by default
  • script-src — scripts only from your domain and one trusted CDN
  • frame-ancestors 'none' — your page cannot be embedded in an iframe (clickjacking protection)

Common pitfalls

unsafe-inline — allowing inline scripts largely defeats XSS protection. Use nonces or hashes instead.

Starting too strict — a CSP that's too restrictive will break your site. Use Content-Security-Policy-Report-Only first: it applies the policy without enforcing it and reports violations so you can refine the rules before going live.

threatprobe.app's free scan checks for the Content-Security-Policy header and flags if it's missing.

Check your security headers →