Dylan

Content Security Policy (CSP) is a W3C guideline to prevent cross-site scripting (XSS) and related attacks. XSS allows other people to run scripts on your site, making it no 
longer your application running on your site, and opens your whole domain to attack due to “Same-Origin Policy” – XSS anywhere on your domain is XSS everywhere on your domain. (see https://www.youtube.com/watch?v=WljJ5guzcLs)
CSP tells your browser to push least-privilege environment on your application, allowing the client to only use resources from trusted domains and block all resources from anywhere else.
Adding CSP to your site will protect your visitors from:
<ul>
<li>Cross-site scripting (XSS) attacks</li>
<li>Adware and Spyware while on your site</li>
</ul>
This plugin will help you set your CSP settings and will add them to the page the visitor requested. Policy violations will be logged in a database table which can be viewed via an admin page that supplies all the violations, along with counts. Buttons easily allow you to add the sites to your headers or to ignore them.
This plugin also allows you to ignore sites that repeatedly violate your policies. For example, some tracking images will show as violating your policies, but you still don’t want them to run, therefore you can block the site from showing up in your logs – note, however, that the browser will still call your server and your server will still spend resources processing the call.
In addition, this plugin can help you to get on the HSTS Preload list – See https://hstspreload.org/ for details.
<h4>CSP Directives</h4>
CSP allows you to control where your visitors’ browser can run code from.
The W3C specification allows for the following directives:
<ul>
<li>
default-src 
The default-src is the default policy for loading content. If another setting is blank then this setting will be used.
</li>
<li>
script-src 
Defines valid sources of JavaScript.
</li>
<li>
style-src 
Defines valid sources of stylesheets.
</li>
<li>
img-src 
Defines valid sources of images.
</li>
<li>
connect-src 
Applies to XMLHttpRequest (AJAX), WebSocket or EventSource.
</li>
<li>
manifest-src 
Specifies which manifest can be applied to the resource
</li>
<li>
worker-src 
Specifies valid sources for Worker, SharedWorker, or ServiceWorker scripts.
</li>
<li>
font-src 
Defines valid sources of fonts.
</li>
<li>
object-src 
Defines valid sources of plugins. Stops your site becoming the source of drive-by attacks.
</li>
<li>
media-src 
Defines valid sources of audio and video.
</li>
<li>
base-uri 
Limit the values that can be used in the entry.
</li>
<li>
frame-src 
Defines valid sources for loading frames.
</li>
<li>
sandbox 
Enables a sandbox for the requested resource similar to the iframe sandbox attribute.
</li>
<li>
form-action 
The form-action restricts which URLs can be used as the action of HTML form elements.
</li>
<li>
frame-ancestors 
Whether to allow embedding the resource using a frame, iframe, object, embed, etc. in non-HTML resources.
</li>
<li>
plugin-types 
Restricts the set of plugins that can be invoked by limiting the types of resources that can be embedded.
</li>
<li>
report-uri 
URL to post information on violations of the policies you set.
</li>
<li>
require-sri-for 
Require integrity check for scripts and/or styles.
</li>
</ul>
<h4>CSP Entry Syntax</h4>
Note – with version 3 of the CSP specification there has been a move to ‘strict-dynamic’ – see the Upgrade Notice section for more information.
Each directive can take one or more of the following values:
<ul>
<li>
* 
Allows loading resources from any source.
</li>
<li>
‘none’ 
Blocks loading resources from all sources. The single quotes are required.
</li>
<li>
‘self’ 
Refers to your own host. The single quotes are required.
</li>
<li>
‘unsafe-inline’ 
Allows inline elements, such as functions in script tags, onclicks, etc. The single quotes are required.
</li>
<li>
‘unsafe-eval’ 
Allows unsafe dynamic code evaluation such as JavaScript eval(). The single quotes are required.
</li>
<li>
‘strict-dynamic’ 
The trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. The single quotes are required.
</li>
<li>
‘sha-AAAAAAAAA’ 
For scripts and styles that can’t take a nonce the browser will tell you a ‘sha-‘ value you can use. The single quotes are required.
</li>
<li>
‘nonce-AAAAAAAAA’ 
The trust nonce value – this value is automatically generated per page refresh and should not be entered by the user. The single quotes are required.
</li>
<li>
data: 
Allow loading resources from data scheme – usually inline images. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.
</li>
<li>
mediastream: 
Allows mediastream: URIs to be used as a content source.
</li>
<li>
filesystem: 
Allow loading resource from file system.
</li>
<li>
https: 
Only allows loading resources from HTTPS: on any domain. This can be used to block insecure requests.
</li>
<li>
www.example.com 
Allow loading resources from this domain, using any scheme (http/https)
</li>
<li>
*.example.com 
Allow loading resourcs from any subdomain under example.com, using any scheme (http/https)
</li>
<li>
http://www.example.com 
Allows loading resources from this domain using this scheme.
</li>
<li>
/path/to/file/ 
Allows loading any file from this path on this domain.
</li>
<li>
/path/to/file/thefile 
Allows loading this one file on this domain.
</li>
</ul>
<h4>Security Headers</h4>
In addition to the CSP headers, there are other security headers supported, including:
<ul>
<li>
Expect-CT 
Instructs user agents (browsers) to expect valid Signed Certificate Timestamps (SCTs) to be served.
</li>
<li>
Strict Transport Security 
The HTTP Strict-Transport-Security response header (HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.
</li>
<li>
X-Frame-Options 
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
</li>
<li>
X-XSS-Protection 
The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript (‘unsafe-inline’), they can still provide protections for users of older web browsers that don’t yet support CSP.
</li>
<li>
X-Content-Type-Options 
The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.
</li>
<li>
Referrer-Policy 
The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.
</li>
</ul>
<h3>Written By</h3>
This plugin was written by Dylan Downhill, CDO of <a href="https://www.elixirinteractive.com/" rel="nofollow ugc">Elixir Interactive</a> .

WP Content Security Plugin

This plugin was implemented on one of our sites as we needed a CSP. None of the team really knew what one was until I was recommended this plugin. 

It's great. Really great, and highly recommended in helping you get a handle on CSP's

Very Easy Setup, great for understanding CSPS

Block XSS vulnerabilities by adding a Content Security Policy header, plugin receives violations to easily maintain the security policy.

Giuseppe

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 <a href="https://nvd.nist.gov/vuln/search#/nvd/home?vulnRevisionStatusList=published&keyword=XSS%20Wordpress&resultType=records" rel="nofollow ugc">XSS for WordPress’ plugins and themes</a>.
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.
<h3>The main problem</h3>
The main problem with Content Security Policies implemented in the real world is that <a href="https://research.google/pubs/pub45542/" rel="nofollow ugc">they are too weak to really protect your site</a> and that many of them can be trivially bypassed by an attacker.
<h3>The proposed solution</h3>
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.
<h3>The problem(s) with CSP in WordPress</h3>
<ol>
<li>
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 <code><script src=""></code>, the real truth is that in a WordPress project you can have dozens of those scripts included with your plugins and calculate a cryptographic hash for each of them to be included in your CSP header can be a frustrating job. However, there are many browser extensions and WordPress’ plugins that can help you in this job.
</li>
<li>
Inline scripts
WordPress core, and plugins, use inline scripts. For these scripts, you can compute hashes to be inserted manually into your policy, only if these scripts do not change at any page load. Unfortunately, this is not very common, as it is frequent to include variable values calculated server side in inline scripts. And it means that your inline scripts change too frequently to manually add their hashes to your policy. 
This commonly happens when scripts are <a href="https://github.com/WordPress/WordPress/blob/a793be201b9c23dbe8b90a6ecd53ab52336f0f91/wp-includes/script-loader.php#L636" rel="nofollow ugc">“localized”</a>.
</li>
<li>
WordPress has no API to implement nonces for CSP
Even if it is easy to generate a nonce for each page view, this nonce has to be inserted in every script tag used to embed inline scripts in your page as
<pre><code><script nonce="rAnd0m">
 doWhatever();
</script>
</code></pre>
and in your script-src directive:
<pre><code>script-src 'nonce-rAnd0m';
</code></pre>
And, of course, a nonce must be unique for each HTTP response.
</li>
<li>
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:
<pre><code><h1 style="color:blue;text-align:center;">This is a heading</h1>
This is a paragraph.
</code></pre>
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
<pre><code> 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.
</code></pre>
To allow inline styles you need to use ‘unsafe-hashes’ in your style-src directive (that is, in facts, unsafe). 
^
</li>
</ol>
<h3>This plugin approach</h3>
This plugin affords those problems in this way:
<ol>
<li>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.</li>
<li>Then you have to whitelist these contents from plugin admin.</li>
<li>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.</li>
<li>You can choose to use hashes to authorize external scripts (and the plugin will allow you to include Subresource Integrity in your <code><script></code> and <code><link></code>)</li>
<li>You can use hashes or nonces to authorize inline scripts.</li>
<li>You can ask the plugin to refactor your page to not use event attributes (converted in a inline script) and inline styles (converted in an internal CSS).</li>
<li>You can set one or more violations’ report endpoints.</li>
</ol>
The plugin supports multisite installations and has (too) many options documented in inline help.
<h3>Creating a Content Security Policy</h3>
After plugin activation, go to Settings menu and search for CSP Settings submenu. 
The steps you are supposed to do are the following.
<ol>
<li>From the Tools tab, activate the capture of the tags and use your site by visiting all the pages or having your users visit them for a long time long period based on the use of your site (hours or days).</li>
<li>From the Tools tab, perform the data clustering in the database (it can use many server resources).</li>
<li>Go to the Base rules tab and include in the CSP directives the desired values ​​(help you with the table at the bottom of the page).</li>
<li>Go to the external scripts tab, inline scripts tab and scripts invoked by event handlers tab and authorize the execution of all the legitimate scripts present on the pages of your site.</li>
<li>Leaving the tag capture active, activate the policy test (at this stage the plugin will generate some violations of the temporary policy used to record additional values to be included in the directives of your “content security policy”).</li>
<li>After visiting again your site pages, disable the capture of the tags and repeat the previous steps 2, 3 and 4.</li>
<li>Enable site protection.</li>
</ol>
N.B. When you update plugins or themes, if something doesn’t work properly on your site pages, temporarily deactivate the protection and repeat steps 1 to 7.
<h3>Plugin hooks</h3>
<h4>Filters</h4>
<ul>
<li><a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/public/class-no-unsafe-inline-public.php#L419" rel="nofollow ugc">nunil_output_csp_headers_header_csp</a> 
nunil_output_csp_headers_header_csp is available since version 1.2.3 and can be used to modify the Content-Security-Policy header before it is sent to browser</li>
<li>
<a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/src/Nunil_Manipulate_DOM.php#L930" rel="nofollow ugc">no_unsafe_inline_not_sri_sources</a> 
no_unsafe_inline_not_sri_sources can be used to modify the list of external resources that do not support SRI (Subresource Integrity)
</li>
<li>
<a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/mu-plugin/no-unsafe-inline-output-buffering.php#L100" rel="nofollow ugc">no_unsafe_inline_final_output</a> 
no_unsafe_inline_final_output is an internal filter used to manipulate the output of the WordPress process just before the output is sent to the browser.
</li>
<li><a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/mu-plugin/no-unsafe-inline-output-buffering.php#L107" rel="nofollow ugc">no_unsafe_inline_meta_injector</a> 
no_unsafe_inline_meta_injector is an internal filter hook used to inject meta http-equiv=”Content-Security-Policy” if variable is set</li>
</ul>
<h4>Actions</h4>
<ul>
<li>
<a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/includes/class-no-unsafe-inline.php#L213-L217" rel="nofollow ugc">nunil_upgrade</a> Functions hooked on nunil_upgrade will run when the plugin is upgraded
</li>
<li>
<a href="https://github.com/MocioF/No-unsafe-inline/blob/d068711d56c2d7b228b524f640f5e13af3327097/includes/class-no-unsafe-inline.php#L254" rel="nofollow ugc">nunil_output_csp_headers</a> Functions hooked to nunil_output_csp_headers will run when the plugin output the CSP HTTP response header
</li>
</ul>
<h3>Code and libraries</h3>
This version of the plugin uses: 
* to parse HTML: 
 * <a href="https://github.com/ivopetkov/html5-dom-document-php" rel="nofollow ugc">ivopetkov/HTML5DOMDocument</a> on PHP<8.4 and libxml<=2.13.09 
 * <a href="https://github.com/Masterminds/html5-php" rel="nofollow ugc">Masterminds\HTML5</a> on PHP<8.4 and libxml>2.13.09 
 * <a href="https://www.php.net/manual/en/migration84.new-features.php#migration84.new-features.dom" rel="nofollow ugc">\Dom\HTMLDocument</a>: The new ext-dom features with HTML5 support on PHP>8.4 
* <a href="https://rubixml.com/" rel="nofollow ugc">RubixML</a> for machine learning from version 1.1.0 – <a href="https://php-ml.readthedocs.io/en/latest/" rel="nofollow ugc">PHP-ML</a> was used in versions 1.0.x; 
* <a href="https://github.com/opctim/php-nilsimsa" rel="nofollow ugc">opctim/php-nilsimsa</a> to calculate and compare Nilsimsa digests.
The log functions have been taken from 
* <a href="https://github.com/perfectyorg/perfecty-push-wp" rel="nofollow ugc">perfectyorg/perfecty-push-wp</a>, something you should <a href="https://wordpress.org/plugins/perfecty-push-notifications/" rel="ugc">really try</a> if you want to implement web Push notifications in your site.
The complete list of dependencies used in this plugin can be seen in <a href="https://github.com/MocioF/No-unsafe-inline/network/dependencies" rel="nofollow ugc">dependency graph</a> on GitHub.
<h3>Contributions, Issues, Bugs</h3>
Plugin code is hosted on a public repository on <a href="https://github.com/MocioF/No-unsafe-inline" rel="nofollow ugc">GitHub</a>. 
Reach me over there to help and suggest.

No unsafe-inline

No unsafe-inline helps you to build a Content Security Policy avoiding to use 'unsafe-inline' and 'unsafe-hashes'.

WP Content Security Plugin vs No unsafe-inline