Use script helper functions in admin to enable Content-Security-Policy opt-in

[westonruter]

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 ​example plugin) to a Strict Content-Security-Policy (​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 ​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.

[bedas]

Can I ask a clarification? I am confused on the "version" of this trac
It says 5.7 and the selector only allows up to 5.7.2

Yet the trac was opened just 5 weeks ago, during a 6.x WP Version "timeframe". I am confused :)

What I am ultimately wondering is if there are ways already available for the _backend_ to become CSP ready, or if we only yet have https://core.trac.wordpress.org/ticket/39941 which implemented a front end filter allowing us to somewhat filter those script tags and add a nonce...

Thank you for any information!

[westonruter]

Replying to bedas:

Can I ask a clarification? I am confused on the "version" of this trac
It says 5.7 and the selector only allows up to 5.7.2

Good question. The version field here refers to when the first applicable version of WordPress that the issue is relevant to. Since the functions were introduced in 5.7, that's why this version is used.

The target version for fixing the issue is captured in the "milestone" field, which is still just Future Release. There isn't currently an established way to opt-in to CSP for the backend, so that's what this ticket is for.

[bedas]

Replying to westonruter:

Thanks! Makes sense now.

I guess then there is some issue with wp_inline_script_attributes, because if it is intended for front end, then it shouldn't run in the backend - but does, and misses the array key type in that case.
I also notice that the documentation for the related wp_get_inline_script_tag is wrongly saying to use wp_script_attributes to filter the tags.

I guess I will open a commit/trac for the latter one and, should I open a trac for the first one? the very least we would need to specify on the doc page that this needs to be hooked explicitly to front end, or that an isset() should be run (which IMO is quite uncommon for filters/hooks, usually they run only where the data is available)

Finally, what about style tag? This is as far I see also not yet implemented (neither in the front nor in the backend)
Is there already a trac for that?

Please stop me if I am wrong. Thanks!

[westonruter]

Replying to bedas:

Replying to westonruter:
I guess then there is some issue with wp_inline_script_attributes, because if it is intended for front end, then it shouldn't run in the backend - but does, and misses the array key type in that case. [...] the very least we would need to specify on the doc page that this needs to be hooked explicitly to front end, or that an isset() should be run (which IMO is quite uncommon for filters/hooks, usually they run only where the data is available)

This filter is not specific for the frontend. It is intended to be used in any context, whether frontend or admin. The type array key is only supplied automatically if the page is not HTML5. So yes, an isset() check should always be done for $attributes['type']. If it is not set, then it is assumed to be text/javascript, per the HTML spec.

I also notice that the documentation for the related wp_get_inline_script_tag is wrongly saying to use wp_script_attributes to filter the tags.

Good catch. The phpdoc for wp_get_inline_script_tag() needs to be updated.