We just scanned our WP website to check the security issues, and we found two issues related to Marketo forms. Do you have any solutions to resolve them?
Any solutions?
Solved! Go to Solution.
- Script Src Integrity Check: app-ab24.marketo.com/js/forms2/js/forms2.min.js can't generate SRI Hash, so, we can't pass this check. FYI, the description of this check:
There’s no reason you can’t generate an SRI hash for that file. Of course if the file changes (i.e. is updated by Marketo, as naturally happens) your hash will become invalid, which is exactly what should happen.
Your choice is either (a) to monitor the file for changes and change the hash immediately or (b) make a copy of the file, upload it to Design Studio, and use that static copy — which of course means you will miss updates.
CGI Generic Cross-Site Request Forgery Detection: it is also related to Marketo forms, the problem shows that on the pages we used Marketo forms. CGIs are not protected by a random token.
There’s no “CGI” (as in cgi-bin) involved here. Sounds like a generic form check.
It’s true that Marketo forms don’t use a CSRF token/nonce. This is true of the overwhelming majority of embedded marketing forms from any vendor, though. Such forms are by their nature anonymously submitted and are not considered to pose the danger of, say, an actual web app. (I’m not passing judgment on whether that assessment is correct, but it’s near-universal.) If an attacker wished to submit a Marketo form to your instance, they wouldn’t need to hit the form endpoint directly, they could just embed the form itself!
- Script Src Integrity Check: app-ab24.marketo.com/js/forms2/js/forms2.min.js can't generate SRI Hash, so, we can't pass this check. FYI, the description of this check:
There’s no reason you can’t generate an SRI hash for that file. Of course if the file changes (i.e. is updated by Marketo, as naturally happens) your hash will become invalid, which is exactly what should happen.
Your choice is either (a) to monitor the file for changes and change the hash immediately or (b) make a copy of the file, upload it to Design Studio, and use that static copy — which of course means you will miss updates.
CGI Generic Cross-Site Request Forgery Detection: it is also related to Marketo forms, the problem shows that on the pages we used Marketo forms. CGIs are not protected by a random token.
There’s no “CGI” (as in cgi-bin) involved here. Sounds like a generic form check.
It’s true that Marketo forms don’t use a CSRF token/nonce. This is true of the overwhelming majority of embedded marketing forms from any vendor, though. Such forms are by their nature anonymously submitted and are not considered to pose the danger of, say, an actual web app. (I’m not passing judgment on whether that assessment is correct, but it’s near-universal.) If an attacker wished to submit a Marketo form to your instance, they wouldn’t need to hit the form endpoint directly, they could just embed the form itself!