Allow using Content-Security-Policy without unsafe-inline

[bymiki]

Currently when using Content-Security-Policy with BuddyPress, you must use the unsafe-inline directive because there are some blocks of inline JavaScript in BuddypPress core. This means that the browser cannot protect the user from attacks using XSS vulnerabilities. This is an unsatisfying situation because XSS vulnerabilities can be found in a great number of other WordPress plugins.

I found at least two inline JavaScript:

/* <![CDATA[ */
var BP_Confirm = {"are_you_sure":"\xxxxx"};
/* ]]> */

And

/* <![CDATA[ */
var BP_DTheme = {"accepted":"xxxr"};
/* ]]> */

[DJPaul]

Thanks for writing, @bymiki.

I can't talk for all instances, but for these two, they are dynamic variables which handle translations for UI elements. This means we can't put them into a JS file. Both come from use of WordPress' wp_localize_script() function, which means you're going to have the same problem with parts of WordPress.

I think this quite topical at the moment, because WordPress' Gutenberg feature requires translated strings, and I know there's work going into WordPress to improve and perhaps change how JS translations and other dynamic strings (nonces, etc) are handled.

See ​#WP10237 and ​#WP32067, and the myriad of linked tickets from those (​#WP39941, and so on).

I think because we have so few contributors compared to WordPress (by orders of magnitude), this is an area we don't have resources to pioneer a solution for, and I'd argue we don't *need* to, given the focus in WordPress itself around this sort of area.

If a future WordPress changes the APIs in a backwards compatible fashion, BuddyPress is fixed. If the WordPress community finds a different approach to solve this, then yes, we'll update.

Thanks for the suggestion, and I apologise that I can't say "we'll fix this soon".

[bymiki]

I Understand. Thank you @DJPaul