Content-Security-Policy warning

You can change the setting to be whatever you need.

John,
Thanks for your reply, I am new to editing security headers and am looking for some advice.

It’s not something I can really advise about as it is specific to the needs of your site. There are online tools that will help you create the header, and that’s probably the easiest way to tune it to fit your site. The plugin just provides a ‘default’ that attempts to not break things.

Also, I don’t know what you mean by ‘scan the site’, and whatever tool you are using may be flagging things that you need to use. I imagine that the term ‘dangerous’ should really be ‘potentially dangerous’.

1. “This policy contains ‘unsafe-inline’ which is dangerous in the script-src directive.” is really dangerous because such CSP does not protect against XSS.
If there is an XSS vulnerability on the web-page, it can be easily exploited for inserting any inline scripts.

2. An 'unsafe-eval' in the script-src counts as ‘potentially dangerous’, even myaccount.google.com and account.google.com pages use it. But in some conditions 'unsafe-eval' can become very dangerous.
For example if you allow some public CDN in the script-src, in case of XSS attacker can load AngularJS or VueJS library with symbolic code execution. In this case, the attacker will no longer need to insert inline scripts – he will simply inject HTML markup like:

<div ng-app ng-csp>{{$eval.constructor('alert(\'XSS\')')()}}</div>

3. An ‘unsafe-inline’ in the style-src directive is really ‘potentially dangerous’.

So your CSP:
default-src ‘self’; script-src ‘unsafe-inline’ ‘unsafe-eval’ http:; style-src ‘unsafe-inline’ http:; img-src http: data:; font-src http: data:; sandbox allow-forms allow-scripts

is not protect against XSS. An ‘unsafe-inline’ allows to inject any inline scripts, and ‘unsafe-eval’ + http: allows to load any framework from public CDN and inject scripts via HTML markup.

• This reply was modified 3 years, 2 months ago by granty.