This has been brought up before, but I think it needs real addressing so that site owners can implement good Content Security Policies (CSP). I have also made a request through the road map. I thought I would outline the issue here and see if anyone else has an issue with this and if they have found a way to get around it until this feature is implemented.
A post was made back in Mar 2020 (Content-Security-Policy (CSP) header validation) and was quickly shut down as a “contact support”. Really this is a feature that helps with security of sites and those who wish to implement correct security policies.
The main thing to address is the addition of some JS code that is inserted into the <head> tag of pages that contain forms on them. This beginning part of this code is shown below…
Honestly I think this is a bit of a hack, but whatever works I guess as long as it is following CSP guidelines of supporting a nonce attribute. For reference of CSP you can checkout this page… CSP: script-src - HTTP | MDN
Without the <script type="text/javascript"> supporting a nonce attribute, site owners are going to be forced to support unsafe-inline as part of their script-src policy.
You can find the code that implements this JS insertion in common.php, function output_hooks_javascript() around line 5666.
What I propose is simply adding a setting that allows users to enter a nonce they can use (or even have it generated but retrievable through code) that then gets printed in that output_hooks_javascript function.
I see the amount of effort for this rather low and would be a good service to your site owner community.
If anyone has any thoughts, please do let me know.
I am not sure that works. Those functions would work if we were using those functions to generate the <script> tags to begin with. But Gravity forms actually just echos out the actual <script type="text/javascript"> tag in common.php, function output_hooks_javascript() on line around 5666. I don’t think WP even really sees such a tag.
Perhaps I am reading it wrong, but my initial testing shows that it doesn’t impact any script tags that a plugin or theme may directly be echoing out. Now I think that if Gravity Forms was to use one of those functions to actually output the <script> tag, THEN we would get access to filter them.
Am I missing something?
Edit: Oh I see you guys are calling this code from multiple locations and not just common.php. I also see you are using those functions. Looks like I will need to do further testing.
Ok well after significant digging through gravity forms and through the WP codebase and documentation from that link you posted, I realized the documentation for showing the attribute filtering is wrong. Here is the wrong info and how it is actually…
Example of use
Adds a nonce attribute to every script tag generated by either wp_get_script_tag or wp_get_inline_script_tag:
function wporg_my_wp_script_attributes( $attr ) {
if ( ! isset( $attr['nonce'] ) ) {
$attr['nonce'] = get_my_custom_nonce(); // Random custom function
}
return $attr;
);
add_filter( 'wp_script_attributes', 'wporg_my_wp_script_attributes' );
In fact inline scripts are using the filter wp_inline_script_attributes. So the statement about wp_script_attributes does not apply to wp_get_inline_script_tag. Once I discovered this, this filter will work for adding the required nonce.