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

WordPress Trac noreply at wordpress.org
Mon Feb 1 19:08:46 UTC 2021


#39941: Allow using Content-Security-Policy without unsafe-inline
-------------------------------------------------+-------------------------
 Reporter:  tomdxw                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.7
Component:  Security                             |     Version:  4.8
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:  javascript
  note                                           |
-------------------------------------------------+-------------------------

Comment (by adamsilverstein):

 @jadeddragoon thanks for your detailed feedback on this proposal. Your in-
 depth knowledge of and passion for CSP is evident in your comments and I
 appreciate the input. Coming from the WordPress core side, our goal is to
 add CSP support to make WordPress more secure.

 I completely agree with you that this approach adds no security ''once a
 site is compromised to the point that a user can call our CSP enabled API
 directly''. (In general WordPress does not provide any PHP side boundaries
 for plugins or themes). A malicious plugin for example, could use our API
 to output a script tag with the correct nonce to pass as "secure".

 Where CSP could help is in preventing content-based ''privilege escalation
 attacks'', for example when an unprivileged user is able to create some
 content that includes a script tag.  Then later (due to a lack of output
 escaping in a plugin for example) another more privileged user later
 triggers that JavaScript in `wp-admin`, causing some unknown side effect
 (user is escalated to admin). If `wp-admin` operated in Strict CSP mode,
 this hack would not be possible.

 In other words, our CSP implementation does not hope to prevent malicious
 scripts served up by the WordPress/the web server from executing - this is
 probably not possible. Instead we aim to prevent scripts injected in
 content from executing. In addition, we aim to provide an API (and
 example) plugins and themes can use to also serve their scripts with
 strict CSP compliance.

 Does this use case make more sense from your perspective?

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


More information about the wp-trac mailing list