[wp-trac] [WordPress Trac] #59446: Use script helper functions in admin to enable Content-Security-Policy opt-in

[WordPress Trac]

#59446: Use script helper functions in admin to enable Content-Security-Policy opt-
in
----------------------------+-----------------------------
 Reporter:  westonruter     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Future Release
Component:  Administration  |     Version:  5.7
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  javascript
----------------------------+-----------------------------
Description changed by westonruter:

Old description:

> In #58664 the script helper functions—`wp_get_script_tag()`,
> `wp_print_inline_script_tag()`, `wp_get_inline_script_tag()`—were
> leveraged to eliminate manual construction of script tags on the frontend
> and the login screen. These were introduced in #39941. This made it
> possible to opt-in (see
> [https://gist.github.com/westonruter/c8b49406391a8d86a5864fb41a523ae9
> example plugin]) to a Strict Content-Security-Policy
> ([https://csp.withgoogle.com/docs/strict-csp.html Strict CSP]) to guard
> against any possible XSS exploits. The scope in #58664 was limited to the
> frontend and the login screen because of the sheer number of inline
> scripts printed on the wp-admin. Additionally, the site editor and block
> editors make use of dynamically-constructed script tags in the editor
> iframe which is a Strict CSP violation.
>
> Much of the work to rework inline scripts to use
> `wp_print_inline_script()` in the admin can be seen in an
> [https://github.com/WordPress/wordpress-develop/pull/498 existing PR]
> (now stale) from @enricocarraro.
>
> See also #59444 which is about how to improve the developer experience of
> working with these JavaScript string literals.

New description:

 In #58664 the script helper functions—`wp_get_script_tag()`,
 `wp_print_inline_script_tag()`, `wp_get_inline_script_tag()`—were
 leveraged to eliminate manual construction of script tags on the frontend
 and the login screen. These were introduced in #39941. This made it
 possible to opt-in (see [https://github.com/westonruter/strict-csp example
 plugin]) to a Strict Content-Security-Policy
 ([https://csp.withgoogle.com/docs/strict-csp.html Strict CSP]) to guard
 against any possible XSS exploits. The scope in #58664 was limited to the
 frontend and the login screen because of the sheer number of inline
 scripts printed on the wp-admin. Additionally, the site editor and block
 editors make use of dynamically-constructed script tags in the editor
 iframe which is a Strict CSP violation.

 Much of the work to rework inline scripts to use
 `wp_print_inline_script()` in the admin can be seen in an
 [https://github.com/WordPress/wordpress-develop/pull/498 existing PR] (now
 stale) from @enricocarraro.

 See also #59444 which is about how to improve the developer experience of
 working with these JavaScript string literals.

--

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