A WordPress Content Security Policy That Does Not Break The Site.

A stock WordPress page carries nine inline script blocks. That is why our own CSP still allows unsafe-inline, and here is the honest path forward.

Aditya Sharma·9 min read

Short answer: deploy the four low-risk directives today, run everything else in report-only mode for a week first, and accept that a wordpress content security policy will probably keep 'unsafe-inline' for scripts unless you control the whole stack. That last part is a real constraint of the platform, not a failure of effort.

Our own policy still has it. Here it is.

Our CSP, including the weak part

The live Content Security Policy header from protuno.com, showing thirteen directives with unsafe-inline highlighted in script-src and style-src, and object-src none, base-uri self, form-action self, frame-ancestors self and upgrade-insecure-requests highlighted as strong
Read live on 7 September 2026. The green directives are doing real work and cost

nothing. The two red ones are the compromise, and they mean this policy stops an injected external script but not an injected inline one.*

I could have written this post without showing that. It would have been less useful.

'unsafe-inline' in script-src substantially weakens a CSP, because the most common injection is an inline