Inline javascript event handles interfere with CSP

Gravity Forms seem to always have inline event handlers - is there anyway to make these not inline? Otherwise we need to add “unsafe-inline” to our CSP or create hashes for every bit of inline js that GF creates…

This has been asked before without any answer but I would assume will become more of an issue with more security awareness and stricter CSPs…

TIA

1 Like

Hey @crawford ,

Good point. We are using the following htaccess rule with no issues:

Header set Content-Security-Policy "img-src * 'self' data: https:; base-uri 'self' data: https:; object-src 'none'; upgrade-insecure-requests"

Also, we have found this particular site header checker useful in identifying security header issues.

Last, we are using the plugin Perfmatters (MU Mode), to remove assets (inline JS and CSS files) from pages that do not contain a Gravity Form.

Not sure this is what you’re looking for, but hopefully, will help you a bit.

Cheers!

@crawford

In short: no there’s no way (without using other plugins/code that filter inline JS).

I asked the same question to support a while ago and submitted it to the roadmap page (but not added to the list by GF). It seems this security issue has no priority at all…

Here the conversation:

Me:

Gravity Forms adds inline scripts to e.g. the submit button (see below). This makes it impossible to set a Content Security Policy without ‘unsafe-inline’. What can I do to use GF with a CSP without using ‘unsafe-inline’? And are there plans to move inline Javascript to files?

<input type="submit" id="gform_submit_button_135" class="gform_button button gfcom-btn gfcom-btn--dark" value="Submit" onclick="if(window["gf_submitting_135"]){return false;} if( !jQuery("#gform_135")[0].checkValidity || jQuery("#gform_135")[0].checkValidity()){window["gf_submitting_135"]=true;} " onkeypress="if( event.keyCode == 13 ){ if(window["gf_submitting_135"]){return false;} if( !jQuery("#gform_135")[0].checkValidity || jQuery("#gform_135")[0].checkValidity()){window["gf_submitting_135"]=true;} jQuery("#gform_135").trigger("submit",[true]); }">

Support:

You can suggest adding CSP support directly to our product management team for consideration when planning future releases on our roadmap page at https://www.gravityforms.com/gravity-forms-roadmap/?c=submit-idea

Me:

So right now it’s not possible to use GF with a CSP without using ‘unsafe-inline’? And what about https://docs.gravityforms.com/security/#h-content-security-policy?

Support:

The filter mentioned in that article only applies tags output in the page header. CSP is not supported for the form specific inline scripts.

@smeedijzer Thanks for the reply!

it’s a real issue - I see more clients looking to tighten up their CSPs and in this case it’s going to mean we have to move away from GF as there is no solution…

We face the same problem…

I contacted them with this issue before and submitted a roadmap idea, but so far it hasn’t even moved to the roadmap. I don’t think they get how important this is, because we will have to discontinue using Gravity Forms for a couple of (big) clients as well, if there is no solution soon.

Maybe losing some subscribers doesn’t make a dent overall but if it were up to me I would want to keep those big customers who’s priority it is to abide to CSP because they are your showpiece.

Maybe someone from the Gravity Forms team can shed some light on this? I know the recommended way is to file a roadmap idea, but since there is no feedback on this and apparently multiple parties are asking, I am wondering if this even has a chance of being applied.

Is the demand not high enough?

I really don’t understand why security isn’t priority number 1 at Gravity Forms. It feels like they are ignoring the issue by not responding to this thread…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.