Support » Plugin: Wordfence Security - Firewall & Malware Scan » Wordfence Blocks Ninja Forms 3 AJAX Form Submission

  • Resolved leewaycreative


    Latest versions of Wordfence and Ninja Forms 3. Form submissions are not working. Console shows 403 Error to /wp-admin/admin-ajax.php. Wordfence says:
    blocked by firewall for XSS: Cross Site Scripting in POST body: formData=%7B%22id%22%3A%223%22%2C%22fields%22%3A%7B%2243%22%3A%7B%22value%22%3A%22%3Ch3%3EPERSONAL%20Info%3C%… at

    Ninja Forms says they don’t know why Wordfence would think their form submissions are malicious XSS. I don’t want to remove checking for XSS site-wide, and if I whitelist, I believe it only will whitelist it for my current IP address, so that’s not a real solution. And in Ninja Forms 3 all form submissions are via AJAX, it can’t be turned off.

    Anybody have ideas how to get Ninja Forms and Wordfence to play nice? Why can’t we all just get along? πŸ™‚

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Hi @leewaycreative,

    Can you confirm that the /wp-admin folder isn’t password protected?

    This can have a significant impact on ALL ajax in WordPress for non-logged in users.



    Not a password protection thing. Nor a “can’t we all just get along” thing. πŸ™‚

    WordFence is detecting a potentially dangerous XSS style pattern in the posted data formats, and hence blocking it.

    I use a lot of ModSecurity rules, that essentially does what the WordFence firewall does, plus a lot more.
    During initial setup, I have to create exceptions as “normal” things get blocked.
    One has to turn some of those rules OFF for specific WordPress paths, such as wp-post.php, wp-post-new.php, or even form plugin POSTings, because some of the patterns being sent in those normal POSTs are in fact potentially bad patterns. When done outside these special cases. Even WordPress’ constant use of the ‘<–more’ tag in normal blog-postings get caught by some rules, which then block those postings.

    However, with ModSecurity, I have the option to turn a particular “rule” off. Not
    across everything (which would be dangerous), but simply turn it off for that particular action.. That specific WordPress path, like wp-post.php.

    Not so in WordFence. It runs the same “potentially bad actions” patterns as used in typical ModSecurity rule-sets, but does not have the option to turn them off individually by a user.. Only the WordFence code can create such “rule exceptions” for specific paths.

    For Ninja Forms and WordFence to “live together”, either the catching rule would have to be removed entirely (dangerous unless it is a badly formatted rule), or WordFence would need a programmed exception for Ninja Forms.

    @leewaycreative, They would need the full content of the POST (or test it with Ninja Forms themselves) to see what is being caught as bad. The goofy URLencoded string you show above simply means

    {"id":"3","fields":{"43":{"value":"<h3>PERSONAL Info

    which is not bad content. Just standard JSON formatted form stuff. There is a lot missing.

    Plugin Author WFMattR


    Hi @leewaycreative,

    I work with @wfyann and took a look at the issue too, and also did some testing with Ninja forms. It looks like the “References” and “Shelter Experience” sections have embedded “style” tags that shouldn’t normally be there — based on the content, it looks like it happened because the text was copied from a Microsoft Word document, and Microsoft sometimes includes strange and unnecessary things in copied data. πŸ™‚

    I think the easiest way to fix it is to edit the form and remove those unnecessary style tags.

    First, temporarily set the Wordfence Firewall to “Disabled” just for a few minutes — you can find it on the Firewall page on the Wordfence menu. Next, edit the form that is having the problem — for the “Shelter Experience” and “References” labels, click the gear icon to edit them, and then where the label text appears under the Default Value heading, click the <> button at the end of the toolbar. You should be able to see the “style” tags under the “h3” heading at the top. Everything between the opening and closing style tags should be ok to remove, including the style tags themselves. Make sure to edit both of those labels.

    Next, be sure to remember to re-enable the firewall when finished. (Turning it off just makes sure that you wouldn’t be blocked while taking the extra html out of the form.)

    Let us know if this helps, or if you have any questions!

    -Matt R

    Y’all rock. The sneaky MSOffice code appears to have been the culprit. Removed and the form is passing Wordfence’s rules with no problems now.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Wordfence Blocks Ninja Forms 3 AJAX Form Submission’ is closed to new replies.