Why does the "Content-Security-Policy (CSP)" check matter?

XSS (malicious code injection) attacks are among the most common on the web. A good CSP can block them almost entirely. It's especially important if the site accepts user-generated content.

How to fix "Content-Security-Policy (CSP)"?

First deploy in report-only mode (`Content-Security-Policy-Report-Only: default-src 'self'`) to identify blocked resources without impacting users. Fix each violation, then switch to `Content-Security-Policy`. Avoid `'unsafe-inline'` and `'unsafe-eval'`. Use Google's **CSP Evaluator** to validate your final policy.

Security Check n°7 / 120

Content-Security-Policy (CSP)

CSP is like a guest list for your site. It tells the browser: "Only load scripts from these approved sources". This prevents attackers from …

Analyse my site for free

← All checks

What is it?

Understanding "Content-Security-Policy (CSP)"

Content-Security-Policy (CSP) is a powerful HTTP header that precisely defines which resources (scripts, styles, images, fonts, iframes…) your site is allowed to load and from which origins. It is the primary defence against XSS (Cross-Site Scripting) attacks, which involve injecting malicious code into your pages. Without CSP, if an attacker successfully inserts JavaScript into your content, that code runs with all the privileges of your domain.

A well-configured CSP drastically reduces the XSS attack surface. It can also prevent data exfiltration attacks (where malicious code sends data to an external server) and clickjacking (via the frame-ancestors directive).

❌ Without CSP — all scripts execute

⚠️ Injected XSS script
via comment, field…

→ no control →

🔴 Executed · Data theft

✅ With CSP — whitelist of allowed sources

⚠️ Unauthorised script

→

🛡️ CSP checks
script-src 'self'

→ blocked ❌

✅ Script from cdn.mysite.com

→ allowed (on whitelist) →

Executed ✓

How we check it

How TheSiteFuse checks "Content-Security-Policy (CSP)"

TheSiteFuse retrieves the response headers and looks for the Content-Security-Policy header (or Content-Security-Policy-Report-Only in audit mode). The check verifies the header's presence and analyses its main directives: default-src, script-src, and the presence or absence of 'unsafe-inline' and 'unsafe-eval'.

Risks if it fails

Why "Content-Security-Policy (CSP)" matters

Missing CSP exposes your site to XSS attacks, listed in the OWASP Top 10:

Stored XSS — malicious code inserted in your database (comment, user profile) executes in the browser of every visitor viewing the page.
Reflected XSS — a malicious link containing code in URL parameters is clicked, and that code executes in the context of your site.
Data exfiltration — injected code can read cookies, localStorage, login forms and send this data to a remote server.
Defacement — injected code can modify the visible content of your pages to deceive visitors.

How to fix

Fix "Content-Security-Policy (CSP)" step by step

Step 1 — Deploy in report-only mode (no impact)

Header always set Content-Security-Policy-Report-Only "default-src 'self'"

Step 2 — Identify and fix violations

Content-Security-Policy: default-src 'self';
  script-src 'self' https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;

Step 3 — Switch to blocking mode

Replace Content-Security-Policy-Report-Only with Content-Security-Policy.

Dangerous directives to avoid

'unsafe-inline' in script-src — allows inline scripts, greatly reducing XSS effectiveness.
'unsafe-eval' — allows eval(). Avoid unless absolutely necessary.
* in script-src — allows all external scripts. Equivalent to no CSP.

Learn more

Reference resource

To deepen your understanding of the technical concepts behind this check, see the dedicated Wikipedia article.

Wikipedia — Content-Security-Policy (CSP)

Does your site pass this check?

Run the free full audit (120 checks) and instantly discover what needs fixing.

Previous HTTP security headers Next Clickjacking protection