If you’re running a WordPress site secured by WPMU DEV’s security plugin, Defender, and suddenly your contact forms stop sending data to external services like CRMs or automations, Defender’s firewall rules might be the culprit. While Defender does an excellent job at protecting sites from threats, its default or strict rules can sometimes block legitimate outbound webhooks—particularly with contact forms like those powered by Gravity Forms, WPForms, or Contact Form 7.
TL;DR
WPMU DEV’s Defender firewall can mistakenly block outgoing webhook deliveries from contact forms, stopping data from reaching third-party tools like CRMs or automation platforms. This happens because the firewall interprets these outbound calls as potential threats. To fix it, you need to whitelist the webhook URLs or adjust specific firewall rules within Defender. Follow our step-by-step guide below to restore webhook functionality while keeping your site secure.
What Went Wrong?
Imagine logging into your analytics dashboard only to realize that your leads have flatlined. You check your forms—they appear to submit normally—but your CRM is strangely quiet. That’s often the first sign that something’s wrong.
After some digging, you find that the contact form submissions are no longer reaching tools like:
- HubSpot
- Zapier
- MailChimp
- ActiveCampaign
The issue? The webhooks—outbound HTTP requests sent by your form handler—are silently blocked somewhere between your site and their destination.
Enter Defender Firewall
WPMU DEV’s Defender plugin includes a Web Application Firewall (WAF) offering bot protection, 404 detection, login masking, and more. One of its more aggressive features involves blocking HTTP requests that match certain patterns or rate thresholds. It’s designed to stop malicious POST and GET requests—but not all requests considered “suspicious” are actually bad.
In particular, Defender’s Path Exclusion and firewall rules sometimes intercept outbound webhooks triggered by contact form submissions, especially those that include:
- JSON payloads
- Authorization headers
- External API endpoints
The origin of the request—usually your WordPress site—might get unintentionally flagged, resulting in dropped webhook calls without any clear error reporting.
Symptoms of Broken Webhooks
Here’s how to diagnose the issue:
- CRM not receiving data: Leads stop appearing even though website forms submit normally.
- No error messages: The user sees a success message, but nothing is delivered.
- Check Webhook Logs: Third-party services like Zapier may report a “timeout” or “403 forbidden” error in their webhook logs.
- Developer Console Network Tab: Some outbound webhook calls don’t complete or return status codes like 403 or even 503.
You might also notice Defender firewall logs listing blocked requests with IP addresses matching your own server—which shouldn’t happen under normal conditions.
Step-by-Step Fix: Restoring Webhook Functionality
Here’s how to unblock those mission-critical webhook connections while maintaining the integrity of your site’s security.
Step 1: Confirm the Issue
- Submit a form entry and check whether the associated third-party service received anything.
- Review logs on both ends: your WordPress log and the webhook destination’s activity logs.
- Log into WPMU DEV and examine Defender > Firewall > Logs for blocked requests around the time of form submissions.
Step 2: Create URL or Path Exclusions
This is often the most reliable fix for restoring broken webhooks.
- Go to Defender > Firewall > Advanced Tools.
- Open the section labeled Ignore Paths or Whitelisted Paths.
- Identify the PHP file or REST endpoint handling your form’s webhooks (e.g.,
/wp-json/gf/v2/entries). - Add this specific path to the exclusions list.
This tells Defender to ignore any requests to or from that path, avoiding false positives.
Step 3: Adjust Request Filtering Rules
- Navigate to Defender > Firewall > Request Filtering.
- Under suspicious keywords or rate-limiting, either:
- Exclude the webhook URL pattern
- Raise the request threshold
- Disable aggressive filtering temporarily to re-test
Step 4: Whitelist Your Server IP (Advanced)
If your WordPress site is making internal HTTP requests (especially common with REST API webhooks), Defender may mistakenly block your own IP.
- Go to Defender > Firewall > IP Banning
- Manually add your server’s IP address to the Whitelisted IPs section
- Re-test form submissions to ensure data flows
Step 5: Test Everything
- Submit new test forms and monitor data delivery to the third party
- Use browser dev tools or webhook testing tools to inspect payloads
- Check Defender’s logs one more time for stray blocks
It’s a good idea to simulate different user behaviors to confirm that no edge cases still break when Defender is protecting the site.
Long-Term Prevention Tips
To avoid issues like these in the future, follow these best practices:
- Document Third-Party Webhook URLs: Know which paths are critical for data transmission.
- Monitor Firewall Logs Regularly: Set a schedule to review logs weekly or monthly.
- Use Staging Before Updates: Always test major security plugin updates in a staging environment.
- Combine Defender with Uptime Monitoring: Tools like Uptime Robot or even WPMU DEV’s own tools can notify you when transactions drop out.
Conclusion
There’s a fine balance between solid security and operational reliability. WPMU DEV’s Defender plugin offers powerful protection, but sometimes that protection crosses into territory that blocks legitimate activity, especially when webhooks are involved. The good news? You don’t have to sacrifice contact form functionality or abandon your integrations with CRMs and marketing automation tools.
Using the step-by-step fixes outlined above—especially around path whitelisting and request filtering—you can have both: secure forms and smooth third-party communication. Your contact forms will be functioning again in no time, and you’ll gain new awareness of how Defender manages firewall rules in the process.
Security is important. But so is your data pipeline. Manage both with confidence!