Few things are more frustrating for web developers and site owners than finding out your meticulously set up contact form is broken—especially after receiving zero submissions for a week during a crucial campaign. That was my exact experience when I discovered that the firewall rules set by Defender by WPMU DEV were silently blocking the webhooks tied to my contact form. If you’re using a similar stack—WordPress, contact form plugins (like Gravity Forms or WPForms), and third-party integrations like Zapier or CRMs—then this is a warning and a guide you can’t afford to skip.
TLDR:
The Defender plugin’s Web Application Firewall (WAF) was blocking outgoing webhook requests from my contact form plugin, causing submissions to fail silently. After days of troubleshooting, I traced the issue to a specific rule blocking ‘application/json’ webhook content. The step-by-step fix involved disabling specific firewall rules and whitelisting the webhook URL manually. Read on to learn how to diagnose and fix this issue if Defender is interfering with your webhooks.
How I Discovered the Issue
It started with silence. Usually, I get at least 4-5 contact form submissions daily through my site, routed via a webhook to a CRM. After a week-long client promotion campaign, I expected a spike—but nada. That’s when the red flags went up.
Here’s how I played detective:
- Checked the contact form plugin logs – no errors.
- Verified that form submissions were being received in WordPress – they were.
- Tested the webhook endpoint manually using a simple POST request – successful!
- Reviewed the server logs and boom — 403 Forbidden errors on every webhook call.
The culprit? A well-meaning rule buried deep inside Defender’s Web Application Firewall.
Understanding What Went Wrong
Defender by WPMU DEV is a solid plugin when it comes to WordPress security, offering features like malware scanning, login protection, two-factor authentication, and a built-in Web Application Firewall. However, its WAF can sometimes be overly aggressive—especially when it comes to webhook-based communication.
My contact form plugin packaged webhook data in application/json content type and sent it via a POST request. Unfortunately, Defender’s firewall rules flagged the outgoing traffic as suspicious, since some default rules block unusual headers, request bodies, and user-agents it can’t recognize. These rules are designed to prevent bot traffic and API abuse, but the collateral damage is real.
Symptoms You Might Notice
If your webhooks are being blocked by Defender’s firewall, here are the tell-tale signs:
- Your contact or lead forms appear to submit correctly but no data reaches the destination endpoint.
- Webhook URLs throw 403 errors in server logs or browser dev tools.
- Email notifications tied to webhook-based automations never fire.
- Dropped submissions that aren’t stored if your form plugin doesn’t log locally.
This is particularly dangerous because everything looks normal on the front end—users don’t see any failure message. The only thing that happens is… nothing. Not great.
Step-by-Step Fix to Restore Webhook Functionality
To fix the issue, I had to do a careful bit of tuning within Defender Firewall. Below is the exact process I followed to restore functionality to my contact forms.
1. Disable WAF Feature Temporarily
This allowed me to confirm that Defender was the root cause. I turned off the Web Application Firewall and suddenly, my webhooks worked perfectly. Don’t leave it off permanently; we’ll fine-tune it instead.
2. Identify the Blocked Requests in Defender Logs
In the Defender admin panel:
- Navigate to Defender > Firewall > Logs.
- Look for log entries around attempted webhook submissions. Filter by type “Blocked requests.”
- Note the exact reason listed for the block: could be “Unauthorized user agent,” “Application/json payload,” or a general WAF policy.
3. Whitelist the Webhook URL
In Defender’s Firewall settings, locate the IP Banning and Whitelisting section:
- Add the destination IP address of the webhook endpoint (you might need to ping the domain to get this).
- If available, use wildcard whitelisting for domain-based endpoints, for example: *.zapier.com.
4. Modify or Disable the Specific Rule
This was the key: I found that the rule blocking ‘application/json’ headers was causing the issue.
- Go to Defender > Firewall > Advanced Rules.
- Locate and review custom or default rules that handle headers or content types.
- Disable only the problematic rule. For example, “Block suspicious content-type headers.”
Note: Avoid turning off entire rule sets unless you’re confident. It’s smarter to isolate the problem than throw out the firewall altogether.
5. Retest Webhook Functionality
Submit a test form and monitor the Logs again:
- Check if the request passes without blockage.
- Ensure the webhook endpoint receives the expected JSON payload.
- Verify that automations like email notifications or CRM logging now work.
6. Monitor Ongoing Status
After things are working, keep an eye on traffic for a few days. Use Developer Tools or a tool like Postman to simulate webhook attempts periodically, just to verify nothing reverts.
Alternative and Preventive Measures
To avoid hitting this problem in the future, I added the following steps into my workflow:
- Always test webhooks after updating Defender or any security plugin.
- Use DNS-based whitelisting for known services like Zapier or Make.com.
- Set up fallback logging inside your contact form plugin so no submission gets lost.
- Enable email failure notices for webhook automations to catch errors early.
And most importantly—
Don’t treat the lack of errors as confirmation that things are working. Assume nothing. Test everything.
Lessons Learned
This experience was a mix of technical frustration and hard-earned insight. Here’s what I took away:
- Security plugins that silently block outgoing requests can be more damaging than helpful without proper logging and alerts.
- Always inspect server logs when something “quietly” fails—they rarely lie.
- The balance between security and functionality is delicate. Regular checks and a testing plan are not optional—they’re essential.
Conclusion
If you’re using Defender WPMU DEV and rely on webhooks in your WordPress stack, pay close attention to your firewall settings. The very tool meant to protect your site can, paradoxically, break it in subtle ways. But with vigilance, the right configuration, and a bit of log-digging, you can have a secure site that’s also fully functional. Hopefully, this guide saves you the days of head-scratching I had to endure.
Back to working contact forms—and better sleep at night.