WordPress and CSP script-src : ‘unsafe-inline’

(Ooops: If you can see this line, please note that I mistakenly posted an incomplete response. I’m editing this post as you read this, so check back later for a more complete response with workarounds)

I see no “problem” to be solved here. Rather, what I see is a lack of understanding of the very purpose of CSP. I’ll attempt a very much unqualified explainer below.

From the super-awesome website — https://content-security-policy.com/ — “Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring, which dynamic resources are allowed to load.”

So if WordPress is throwing errors after implementing a CSP, it simply means your CSP is preventing WordPress from executing some scripts. And, by the way, these errors would not be peculiar to WordPress… ANY other CMS of even static site that needs to execute resources being blocked by a CSP policy will similarly throw errors.

However, from VAPT report, script-src ‘unsafe-inline’ should be removed. If I remove this, the error will comeback.

At its core, CSP defines what “origin” resources are allowed to be executed from.

This is pretty straightforward to implement when you’re handcrafting your own website/webapp and you’re loading all resources from your own domain. But it gets tricky when you’re running a CMS like WordPress, where 33rd-party themes and plugins are loading resources from all kinds of places.

Without knowing your full CSP implementation and what errors you’re getting, I can only say the not-so-useful obvious: that your CSP is blocking some resources from executing, hence the errors, so you should tweak your policy to allow those resources to be executed.

• This reply was modified 3 years, 5 months ago by George Appiah.
• This reply was modified 3 years, 5 months ago by George Appiah.

If there is no workaround, please clearly state that this cannot be done as WP needed this CSP script-src : ‘unsafe-inline’ ‘unsafe-eval’

WordPress doesn’t need any particular CSP policy. It just needs to be able to execute its code. Using script-src : 'unsafe-inline' 'unsafe-eval' is just like disabling your computer’s firewall to get some software to run. The software doesn’t actually need the firewall disabled: it just needs to be whitelisted so it can run without being blocked.

I don’t know your CSP definition and what specific “errors” you’re getting, but the solution to all CSP errors is simply to allow all REQUIRED code to be executed, by whitelisting the origins or domains where those resources are loaded from.

But note that inline scripts are blocked by default, even with scrip-src: self;. This is according to the CSP standard… and has nothing to do with WordPress.

Meanwhile, WordPress, your theme, and all your plugins will likely generate a ton of inline scripts. So even after allowing self and all external domains in your policy, your site may very well still break.

There’s no “workaround” or hack per se for this, but there’s a proper, secure way to implement CSP while allowing inline scripts… which is to use either hashes or nonses for your inline scripts.

On a WordPress site where themes and plugins inject inline code all over the place, that’s easier said than done.

There are SEVERAL CSP plugins out there, but I don’t know if any of them properly handles inline scripts or not. You may want to experiment with some of them to find out: https://wordpress.org/plugins/search/csp/

I understand that this is not the simple YAY or NAY response you were hoping for. But very little of technology (and security in particular) can be reduced to a simple YES or NO answer.

Good luck!