[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:  Future
                                                 |  Release
Component:  Security                             |     Version:  4.8
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-refresh 2nd-opinion  |     Focuses:  javascript
-------------------------------------------------+-------------------------

Comment (by alinod):

 Replying to [comment:34 epicfaace]:
 > What if we instead created a nonce that is only used for scripts loaded
 from WordPress Core, and thus cannot be accessed by the developer for use
 by arbitrary scripts? What do you think, @jadeddragoon and others?
 It seems to me that you might be missing the definition of a nonce.  A
 nonce is a number used only once.  The [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src MDN reference]
 explains it pretty well:
 >**'nonce-<base64-value>'**
 >A whitelist for specific inline scripts using a cryptographic nonce
 (number used once). The server must generate a unique nonce value each
 time it transmits a policy. It is critical to provide an unguessable
 nonce, as bypassing a resource’s policy is otherwise trivial. See unsafe
 inline script for an example. Specifying nonce makes a modern browser
 ignore 'unsafe-inline' which could still be set for older browsers without
 nonce support.

 Therefore a new random value must be generated for each inline script and
 it must be unique across page requests.  In addition, a CSP header must be
 issued that contains the exact same nonce that was randomly generated for
 each inline script.  Without these controls, the CSP is not providing any
 protection since it would be trivial to circumvent.  Clearly, any kind of
 page caching would break the site, if nonces are used.

 Hashes are a much better choice.  However, it is imperative that the hash
 is a static value that only changes when upgrading to a new revision of
 WordPress; calculating the hash at runtime based on the existing content
 of the inline script is no safer than using 'unsafe-inline'.  We would
 essentially be telling the browser to trust everything in the inline
 script, regardless of whether it is malicious or not.  Worse, this would
 mask the underlying vulnerability and give users a false sense of
 security.

 Security practitioners like to call this "security theatre" and for good
 reason.

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