[wp-trac] [WordPress Trac] #64683: _print_scripts should use the wp_inline_script_attributes filter

[WordPress Trac]

#64683: _print_scripts should use the wp_inline_script_attributes filter
---------------------------+------------------------------
 Reporter:  galaxor        |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Script Loader  |     Version:  6.9.1
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+------------------------------
Changes (by sabernhardt):

 * component:  General => Script Loader


Old description:

> On my site, we want to use a content-security-policy:
> https://infosec.mozilla.org/guidelines/web_security#content-security-
> policy. And in this policy, we would like to not include support for
> 'unsafe-inline' scripts.
>
> We can include inline scripts, as long as they have a nonce in them. That
> is, instead of just a <script> tag, if they included a <script
> nonce="xxxxxxx">, where the nonce is generated on every page load, and if
> our Content-Security-Policy contains script-src 'nonce-xxxxxxxx'.
>
> Some of the scripts generated by WordPress core -- and, indeed, by
> plugins -- print themselves out using the wp_get_inline_script_tag
> function. When a script does that, then our theme can add a filter on the
> wp_inline_script_attributes hook, which adds the nonce according to our
> own logic.
>
> However, there are some inline scripts printed by WordPress core that do
> not use wp_get_inline_script_tag, and with these scripts, there is no way
> to for our theme to add a nonce to the script tag, and therefore no way
> to allow these scripts to run in the context of a Content-Security-Policy
> that does not allow 'unsafe-inline' scripts.
>
> The scripts added by WordPress core are at least those that are added by
> wp_default_scripts.   Ultimately, these are printed out using the
> function _print_scripts, in wp-includes/script-loader.php.  It prints the
> script tag using
>
> {{{
> echo "\n<script{$type_attr}>\n";
> }}}
>

> where $type_attr is either the empty string or "type='text/javascript'".
>
> I propose that _print_scripts be changed so that instead of echoing the
> script directly, it constructs the code it wants to output, and prints it
> onto the page using wp_get_inline_script_tag, so that themes or plugins
> can add filters on the wp_inline_script_attributes hook to add a nonce
> (or do anything else).
>
> Is that a good approach?  If so, I can submit a pull request.
>
> If there's another approach that would be better, I could do that.
> Perhaps we want to have a different hook here for some reason.

New description:

 On my site, we want to use a
 [https://infosec.mozilla.org/guidelines/web_security#content-security-
 policy content-security-policy]. And in this policy, we would like to not
 include support for 'unsafe-inline' scripts.

 We can include inline scripts, as long as they have a nonce in them. That
 is, instead of just a `<script>` tag, if they included a `<script
 nonce="xxxxxxx">`, where the nonce is generated on every page load, and if
 our Content-Security-Policy contains `script-src 'nonce-xxxxxxxx'`.

 Some of the scripts generated by WordPress core—and, indeed, by
 plugins—print themselves out using the `wp_get_inline_script_tag`
 function. When a script does that, then our theme can add a filter on the
 `wp_inline_script_attributes` hook, which adds the nonce according to our
 own logic.

 However, there are some inline scripts printed by WordPress core that do
 not use `wp_get_inline_script_tag`, and with these scripts, there is no
 way to for our theme to add a nonce to the script tag, and therefore no
 way to allow these scripts to run in the context of a Content-Security-
 Policy that does not allow 'unsafe-inline' scripts.

 The scripts added by WordPress core are at least those that are added by
 `wp_default_scripts`.   Ultimately, these are printed out using the
 function `_print_scripts`, in `wp-includes/script-loader.php`.  It prints
 the script tag using

 {{{
 echo "\n<script{$type_attr}>\n";
 }}}


 where `$type_attr` is either the empty string or
 `"type='text/javascript'"`.

 I propose that `_print_scripts` be changed so that instead of echoing the
 script directly, it constructs the code it wants to output, and prints it
 onto the page using `wp_get_inline_script_tag`, so that themes or plugins
 can add filters on the `wp_inline_script_attributes` hook to add a nonce
 (or do anything else).

 Is that a good approach?  If so, I can submit a pull request.

 If there's another approach that would be better, I could do that.
 Perhaps we want to have a different hook here for some reason.

--

Comment:

 Related: #58664

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