CSPs weaken cross-site scripting (XSS) attacks by stopping malicious scripts being inserted by attackers.


No CSP found in enforcement mode

Why should you include a CSP (Content Security Policy) in your web pages? Because by doing so, you can be sure that any content loaded on the page is trusted. 

CSPs weaken cross-site scripting (XSS) attacks by stopping malicious scripts being inserted by attackers. The CSP, however, can be circumvented without too much trouble if it is not strictly written. 

If no CSP is found in enforcement mode, SeoChecker will notify you:

csp xss

If you want to be sure that your CSP can not be bypassed, follow these practices:


  • CSP targets XSS


A CSP must have no syntax errors and must include the script-src, object-src and base-uri directives to target XSS.

script-src is intended to protect the page from unsafe scripts, while object-src protects it from unsafe plugins. If you want to configure a more generic and less specific setting, you can use default-src.

base-uri instead prevents the injection of unauthorised <base> tags: these can be used by attackers to redirect all related URLs (such as scripts) to their domains.


  • To avoid allowlist bypasses, CSP uses nonces or hashes


When a CSP configures a script-src allowlist it means that it assumes that all responses coming from a trusted domain are secure and can therefore be executed as scripts. This assumption, however, is not so obvious for modern applications: there are usually common and benign patterns that can be used by attackers to bypass the CSP.

Thus, an attacker can bypass most script-src allowlists with an XSS bug; moreover, allowlists do not grant real protection against script injection. One solution is nonce-based and hash-based approaches.

Take a look at this code that uses a JSONP endpoint hosted on a trusted domain to inject a script controlled by an attacker:


script-src https://trusted.example.com


<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script> 

Therefore, let the CSP use “strict-dynamic” and allow scripts one by one through nonces or hashes.

There are other recommendations besides the previously mentioned:

  • Monitor the breakages configuring a reporting destination. Use the report-uri or report-to directives.
  • If it's possible for you, define a CSP in an HTTP response header:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
  • Considering that nonces and hashes, as well as strict-dynamic, are not supported by all browsers, you should add unsafe-inline and an allowlist as a fallback.


Examples of strict CSP

Strict CSP with a nonce-based policy:


script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;

object-src 'none';

base-uri 'none';

report-uri https://reporting.example.com;


<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>

Share this Guide

Did you like it? Share it!

Share it!

Web tools for modern developers. Try these one!

Over 50 generators, builders and validators to improve your SEO and web performances

Home Back to top of the page