Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.
Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications.
XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.
A cross-site scripting vulnerability may be used by attackers to bypass access controls like the same-origin policy.
Looking at National Vulnerability Database run by US NIST, more than 1100 (November 2025) vulnerabilities are reported as XSS for WordPress’ plugins and themes.

Keeping your site up-to-date with the latest versions of plugins and themes is the first line of defense to ensure your site’s security.

The second thing to do, is to deploy a strict Content Security Policy.

The main problem

The main problem with Content Security Policies implemented in the real world is that they are too weak to really protect your site and that many of them can be trivially bypassed by an attacker.

The proposed solution

Google researchers recommend, instead of whole host whitelisting, to activate individual scripts via a CSP nonces approach.
In addition, in order to facilitate the adoption of nonce-based CSP, they proposed the ’strict-dynamic’ keyword.

The problem(s) with CSP in WordPress

1. Manual creation of a policy

   Usually, a WordPress project is a mix of code written by different authors who contributed to the Core and or wrote plugins and themes.
   If it is possible to whitelist every external script loaded from a

   and in your script-src directive:

   script-src 'nonce-rAnd0m';
   

   And, of course, a nonce must be unique for each HTTP response.

2. Unsafe hashes / Inline styles

   Sometimes, HTML elements as images or buttons use HTML Event Attributes (onclick, onsubmit…) to let events trigger actions in a browser.
   You cannot use hashes or nonces for script included in event attributes and, adopting a strict CSP, requires refactoring those patterns into safer alternatives or to use ‘unsafe-hashes’.
   You got a similar problem when inline styles are used in HTML tags:

   This is a heading
   This is a paragraph.
   

   CSP Level 2 browsers may be ok with just putting the hash in your style-src directive. However, to allow hashes in the style attribute on inline CSS on browsers that support CSP Level 3, you may get an error like this

       Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.
   

   To allow inline styles you need to use ‘unsafe-hashes’ in your style-src directive (that is, in facts, unsafe).
   ^

This plugin approach

This plugin affords those problems in this way:

1. During a capture phase, it detects the scripts, styles and other embedded content present in the pages of your site and stores them in the database.
2. Then you have to whitelist these contents from plugin admin.
3. The plugin uses machine learning to cluster inline scripts trying to aggregate scripts generated by the same server side (PHP) code. So, you can authorize one script example to authorize all scripts that the classifier predicts to label as whitelisted clusters.
4. You can choose to use hashes to authorize external scripts (and the plugin will allow you to include Subresource Integrity in your