Domain security

Does Content Security Policy prevent XSS attacks?

Reviewed 2 November 2026 by the SageRank team

Short answer

A Content Security Policy reduces the damage a cross-site scripting attack can do by limiting where scripts may load from and run, but it does not remove the underlying flaw. Treat it as a second line of defence behind input handling and output encoding, and build it with nonces or hashes, not unsafe-inline.

What CSP adds

XSS happens when a site lets attacker-supplied text run as script. The real fix is to treat user input safely and encode output. CSP is a browser-enforced rule that limits what scripts may run even if something slips through.

A strict starting point

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-RANDOM_PER_REQUEST';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none'

A nonce is a random value created for each response and added to the scripts you trust. An attacker cannot guess it.
Avoid 'unsafe-inline' and 'unsafe-eval' in script-src. They remove most of the protection.
object-src 'none' and base-uri 'none' close two common bypasses.

Roll it out safely

Start with Content-Security-Policy-Report-Only and collect the reports.
Fix or allow the scripts you really use.
Switch to enforcing mode once the reports are quiet.

Limits

A permissive policy, or one that allows a whole third-party domain that hosts user content, can be bypassed. CSP helps against many injection attacks, not all. Keep fixing the source of the flaw.

How SageRank helps

The free report does not test domain security. SageRank’s Sentinel and Ultimate plans run ten levels of domain security checks through ShieldAI. See ShieldAI.