CSP XSS Effective.

Content Security Policy effectiveness against cross-site scripting

What does this check test?

This check evaluates whether the site's Content Security Policy (CSP) effectively mitigates cross-site scripting (XSS) attacks. A CSP is an HTTP header that tells the browser which sources of content are allowed to execute on the page. An effective CSP against XSS avoids `unsafe-inline` for scripts (or uses nonces/hashes instead), avoids `unsafe-eval`, does not use overly broad wildcards in `script-src`, and includes a restrictive `default-src`. Lighthouse evaluates the CSP for known bypasses and weaknesses that would allow an attacker to inject and execute arbitrary JavaScript.

Why does it matter?

XSS remains one of the most common web vulnerabilities — a properly configured CSP is the strongest defense-in-depth mechanism against it. Even if your application has an XSS bug, a strict CSP prevents the injected script from executing. From a performance perspective, CSP also limits which third-party scripts can load, preventing unexpected resource loading that degrades performance. CSP violations are reported to a configurable endpoint, giving you visibility into attempted attacks and misconfigured resources. Sites without CSP or with weak CSPs are significantly more vulnerable to XSS exploitation.

Who is affected?

All websites handling user data, authentication, or sensitive content should implement a strict CSP. Sites with user-generated content (forums, comments, profiles), sites handling financial transactions, and sites subject to compliance requirements (PCI-DSS, HIPAA) have the greatest need. Single-page applications that use JavaScript frameworks are particularly well-suited to strict CSPs because their rendering is controlled and predictable.

Where does this apply?

Check the `Content-Security-Policy` response header on the main HTML document. Chrome DevTools Security panel and Console panel show CSP violations. Common weaknesses: `script-src 'unsafe-inline'` (allows any inline script to run), `script-src 'unsafe-eval'` (allows eval-based attacks), `script-src *` or `script-src https:` (allows loading scripts from any HTTPS origin), and missing `object-src` or `base-uri` directives.

How to fix it

add_header Content-Security-Policy "script-src 'nonce-$request_id' 'strict-dynamic'; object-src 'none'; base-uri 'self'; report-uri /csp-reports";

<script nonce="UNIQUE_NONCE_PER_REQUEST">
  // This inline script is allowed by the CSP
  initApp();
</script>

add_header Content-Security-Policy-Report-Only "script-src 'nonce-$request_id' 'strict-dynamic'; object-src 'none'; base-uri 'self'; report-uri /csp-reports";

References

• Content Security Policy (CSP) — MDN
• Strict CSP — web.dev
• CSP Evaluator — Google