Formidable Forms Triggers Multiple False ModSecurity™ Positives

Introducing Custom OWASP CRS Firewall Rules for Formidable Forms

If you manage your own VPS, dedicated server, or have a site on a shared server that implements Apache's mod_security module with the OWASP ModSecurity 2.9 Core Rule Set v3.3.4 or higher, you'll need to add rules to your server firewall to allow Formidable's form builder, view editor, and Customize HTML screens to work properly.

Background

With the sunsetting of CentOs 9, Ihad to upgrade my dedicated server to AlmaLinux v8.10.0 and cPanel Version 122.0.23. Along with the upgrade came a slew of server security updates.

Using Easy Apache 4, I provisioned Apache's mod_security module with the above mentioned default core rule set. This immediately broke some of Formidable's more important development features such as including jQuery and CSS source code on the Customize HTML page, views, and the form builder itself.

This is a silent video of how the firewall issue manifests:

Video Explainer

1. Entering HTML into the form's Customize HTML After Fields area has no effect. Saving works as expected.
2. Add a jQuery script and the save is blocked by the firewall producing a file not found error.
3. Adding empty script tags blocks the save producing a file not found error.

Opening a ticket with Strategy 11 resulted in this response:

Hi Victor,

Thank you for contacting our support team today. My name is Toyin and I am happy to help.

I am unable to reproduce this https://www.loom.com/share/9899655482e94793aa8035e339d56f0e. It is possible this action is being blocked by the hosting provider.

Can you please check with the hosting team?

Thanks!

Strategy 11 Support

Since I manage my own server, the hosting provider means me. I started troubleshooting. It took almost a full day to conclude that two firewall rules were consistently being violated:

Rule 949110: XSS Filter - Category 1: Script Tag Vector (Warning)
Rule 941160: NoScript XSS InjectionChecker: HTML Injection (Fatal)

Given the seriousness of XSS rules violations, I asked Walter Jones of Jones Web Designs to weigh in with his analysis. In addition to being a top-tier WordPress/Formidable Forms developer, Jones is a data security expert credentialed at the highest U.S. government level.

The fact that you need to modify ModSecurity rules to allow specific content (like script tags) indicates that Formidable Forms might be doing something that triggers OWASP rules designed to prevent XSS attacks. Disabling these rules can potentially make your site vulnerable to XSS if the proper sanitization and validation aren’t handled carefully.  Obviously this is and can be a source of browser based malware delivery.

This is a common vector for attacks like session hijacking, defacement, or redirection to malicious sites. Even if the threat is currently seen as a false positive, creating blanket rules that bypass this protection without implementing strong validation and sanitation could lead to vulnerabilities. Inherently, I believe FF to be safe, I don’t know why the update is causing this now and hasn’t previously.

The suggested modified rules are safe in my opinion because they are specified to this issue. I would caution any blanket rule within ModSec or htaccess.

I concur with this assessment. Formidable is safe and is not a threat to anyone unless bad actors purposefully deploy malware payloads through booby-trapped forms. Formidable is not alone in this. Malware payloads can be delivered through any means and by any form builder that allows for custom code.

I want to emphasize, this issue does not appear to be a security risk to any developer unless the developer aspires to cyber-criminality. Then the risk is based on being found out and facing the consequences.

The bottom line is that there is no risk in continuing to use Formidable to build your applications.

Third Firewall Rule Required

The first two rules were triggered when source code was added to a view or the form's Customize HTML After Fields area. Later when polishing the form in the builder, I experienced another firewall failure when I added a comment to the Custom HTML field or attempted to add a link to a field description.

This time, scouring the mod_security audit.log proved fruitless. The triggered rule was not captured in the log. To correct the problem, I ended up adding a blanket rule for the form builder component. It's definitely not the best practice, but at this point it's necessary to allow Formidable to function as designed.

Strategy 11's Response

I opened the support ticket on October 10, 2024. After discovering the root cause, I replied to Strategy 11 support with my findings and provided the rule set that fixes the problems.

I also contacted Steve Wells through the Formidable Community Forum email system. Strategy 11. This is his response in its entirety.

Hi Victor,
Thank you so much for your detailed feedback and for sharing your findings with us and the broader community. I really appreciate the time and effort you’ve put into identifying the root cause and coming up with a solution that helps both your setup and potentially others who might encounter similar issues.

After reviewing your analysis and discussing it with our lead developer, it appears that this issue stems from how ModSecurity handles script tags, rather than being specific to Formidable itself. The ModSecurity rules you’ve identified are designed to prevent potential XSS attacks, which is why they trigger when scripts are added through Formidable’s “After Fields” section.

It’s important to note that allowing scripts anywhere has security implications. WordPress—and Formidable—support the DISALLOW_UNFILTERED_HTML constant, which prevents adding scripts to “After Fields” HTML if enabled.

We are considering adding more information about ModSecurity interactions in our documentation, particularly around code snippets, to help users better understand potential issues. This should assist others who may encounter similar challenges moving forward.

While we don’t plan to change the plugin behavior—given the security implications of unrestricted script inclusion—your proposed ModSecurity rules are a reasonable solution for those who manage their own servers and wish to safely enable this functionality.

Thank you again for your proactive approach and dedication to improving the Formidable experience.

Best regards,
Steve Wells

Formidable's OWASP Allow Rules Available to Purchase

If you have a self-managed server or your site is on a shared server with mod_security enabled and you are experiencing mod_security issues with Formidable on the latest OWASP rule set, you can purchase the Formidable OWASP rule set here: Formidable Forms OWASP Allow Rule Set.