[wp-trac] [WordPress Trac] #39941: Allow using Content-Security-Policy without unsafe-inline

[WordPress Trac]

#39941: Allow using Content-Security-Policy without unsafe-inline
-------------------------------------+--------------------------
 Reporter:  tomdxw                   |       Owner:  johnbillion
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  5.3
Component:  Security                 |     Version:  4.8
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:  javascript
-------------------------------------+--------------------------

Comment (by jadeddragoon):

 Replying to [comment:25 jrchamp]:
 > Replying to [comment:24 jadeddragoon]:
 > > The CSP is (when done correctly) set in the httpd... independent of
 the site code.
 >
 > Only the application itself will know the elements that need to be
 allowed,

 If you don't use inline javascript at all, then you will know exactly
 which elements need nonces: none of them.

 All javascript should be moved to separate files. The javascript itself
 should be static... not templated via php... and thus not at risk of code
 injection via php. This restiction then allows features of CSP (such as
 strict-dynamic) to work as intended. Then the needed CSP policy would be
 known at deploy time and can be set in an independent application (httpd),
 applying the principle of
 [https://www.owasp.org/index.php/Separation_of_duties separation of
 duties].

 I think people may actually be forgetting that the "scripts" component of
 CSP is referring to **client side code only**. Because the CSP is enforced
 client side it can't tell how or in what way the php is loading scripts or
 really even that php was used... and thus strict-dynamic cannot do
 anything to protect users from poor implementations.

 In the [https://csp.withgoogle.com/docs/adopting-csp.html examples given
 by the very page you linked to]... only the nonce is templated... not the
 javascript. The javascript is static. I see nothing on this site that
 recommends the usage you claim it does such as when, like in the case of
 wordpress, the javascript is templated on the server side before being
 sent to the client.

 If no one wants to put the time and effort into refactoring WP to allow
 this... fine. Make it clear that people need to allow unsafe-inline to use
 wordpress and accept the security hit... don't disguise the security risk
 like this. It's unethical.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39941#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform