Stopping Contact Form Spam at Cloudflare Before It Reaches Your Site

Contact form spam is more than an inbox nuisance on a hosted site. Each fake submission is a full request to your WordPress install: the page loads, PHP processes the form, the database may store the entry and the server sends a notification email. If you already have a captcha on the form and spam still gets through, the more effective place to filter it is in front of the site, at Cloudflare, so automated submissions never reach your hosting at all. This article explains how that works for a site hosted with us and what to check if spam continues.

Why form spam is hard to stop on the server

Server-level security is built to recognise attacks: known exploit patterns, floods of requests, repeated failed logins. A spam submission does not look like any of those. It is one request, at a normal rate, filling in the same fields a genuine visitor would. From the server’s point of view it is a visitor using your form. Filtering by where the visitor comes from and whether it can pass a browser challenge is a better fit, and Cloudflare can do that before the request arrives.

Before you start

• Your domain needs to use Cloudflare, with the website’s DNS record proxied (the orange cloud). If the record is grey-clouded, traffic goes straight to our server and the rule never runs.
• The rule lives in your Cloudflare account, not on the hosting server, so you or whoever manages your Cloudflare account creates it.
• It works on the free Cloudflare plan, which included five firewall rules when the video was recorded.

The rule

In Cloudflare, open Security, then WAF, and create a new rule (newer dashboards list these as custom rules). Click Edit expression and paste the expression below, give the rule a name, set the action to JS Challenge and deploy it.

(http.request.uri.path eq "/contact-us/" and ip.geoip.country ne "AU" and ip.geoip.continent ne "NA" and not cf.client.bot)

In plain terms: anyone requesting the contact page who is outside Australia, outside North America and not a verified bot gets a Cloudflare challenge first. Adjust it before deploying:

1. Change the path to your own contact page, matching the trailing slash exactly as your site uses it.
2. Change the country and continent to your own main markets. A UK business might use ip.geoip.country ne "GB" and ip.geoip.continent ne "EU".
3. Leave not cf.client.bot in place. It stops Google and other search engines being challenged, which would otherwise stop the page being crawled and indexed.

What it will and will not affect

Because the rule matches a single path, the rest of the site is untouched. Uptime monitors, payment gateways, backup services and plugin APIs that call other URLs carry on as normal. That is the main advantage over a site-wide country filter, which catches those services too and needs exceptions adding for each one. Visitors in your main markets never see a challenge, which matters on a page where people are usually about to make an enquiry.

The trade-off is coverage. If your site has forms on other pages, such as a footer newsletter sign-up or a quote form in a sidebar, this rule does not protect them, and a site-wide filter is the better choice.

Checking that it works

Give the rule an hour to a day, depending on your traffic, then look at it in the Cloudflare dashboard. Each rule shows how many challenges were issued and the CSR, or challenge solve rate. Many issued and few or none solved is the pattern you want: automated traffic is being stopped, and people are not being caught. The video shows a comparable rule on a WordPress login page that issued 15 challenges in 24 hours with none solved.

If spam keeps arriving

Some spam tools never load the contact page. They send the form data straight to the URL the form submits to, which for many WordPress form plugins is not the contact page itself. If Cloudflare shows the rule issuing challenges but the spam continues, that is a likely reason. Open a ticket from the client area and include:

• The domain and the contact page URL.
• Which form plugin you use.
• The date and time of two or three recent spam submissions.
• Whether the domain is proxied through Cloudflare and which rules you have added.

With the timestamps our support team can find the matching requests in the server access logs and see exactly which URL the spam was posted to and where it came from, which tells you what to filter next.