I put a WAF on the front door. The spam wasn't using the front door.
There’s a small corporate site. A few days after launch, one piece of spam landed in the contact form.
Zero actual damage. Just a lazy ad. But there were two real problems.
One: no spam protection at all. Two: even when spam arrives, nobody notices (there’s no notification path).
And my hands were already moving. “Put Cloudflare in front, turn on the WAF and Bot Fight Mode, done.”
Pure reflex. The standard prescription that comes out the instant I hear “spam in a contact form.” My hands started sketching the architecture diagram before my brain had said a word.
I hadn’t actually looked at how the form worked yet
Before writing the prescription, I peeked at how the form actually behaves. That saved me.
That form was sending nothing to the site’s server.
JavaScript in the browser, using a public anonymous key, inserts a record directly into the API of a BaaS (= an external service you can write to straight from the browser; a very common setup). That’s the whole thing.
So when you press submit, the request that flies out is:
browser → that external service's domain
It doesn’t touch the site’s own domain by a single millimeter.
…wait.
Cloudflare stands at the front door. The spam comes in the back.
Now let’s revisit that prescription.
Putting Cloudflare in front means: traffic headed for the site’s domain gets intercepted and screened by Cloudflare first. The WAF and Bot Fight Mode both work by inspecting traffic that passes through the domain and blocking it.
But the spam submission doesn’t pass through the domain. It flies from the browser straight to a different host (the external service), a nonstop flight.
You can post the most impressive guard at the front door (the site itself), and the spam simply won’t use the front door. It comes in the back.
For a bot it’s even easier: the anonymous key and the API URL are right there in the public bundle, so it doesn’t even need to open the page — it can just POST directly to the external service’s API. Either way, the site’s domain never sees it.
The diagram I’d been drawing was a guard posted at the wrong door. Embarrassingly, I’d been about to call that diagram “finished.”
So is Cloudflare pointless here? No.
This is the important part: this is not a “Cloudflare was useless” story.
The front door (the site itself) gets other visitors too. Indiscriminate DDoS, vulnerability scanners, badly-behaved crawlers. And at the whole-domain level, it consolidates TLS management, DNSSEC, and settings otherwise scattered across different registrars into one place.
As standardized defense and operations for the whole domain, adding Cloudflare is genuinely worthwhile.
It’s just medicine for a different illness. I was prescribing “domain defense” for a symptom called “form spam.” It doesn’t work — not because the medicine is bad, but because the disease is different.
The real medicine goes where the entrance is
If the spam’s entrance is that external service, the countermeasure has to live there too. In stages, it looks like this.
First, the placebo-that-actually-helps layer. Add a honeypot (a trap field invisible to humans; if it’s filled, it’s a bot) and a time trap (too fast from render to submit = not a human, flag it) to the form. Naive bots mostly die here. The trick is not to block, but to just mark it “smells like spam” so a human can pick it up.
If you want to really stop it, change the structure. Stop letting the browser write to the database directly, and route it through your own verification endpoint first. There, verify a human-check token (something like Turnstile) before writing. And revoke the anonymous key’s direct write permission.
Only now does that verification endpoint live on your own domain — so Cloudflare’s WAF and rate limiting finally apply to the form’s traffic too. Because you changed the design so it goes through the front door, the front-door guard can do its job. The order was just backwards.
Takeaway
We tend to think defense is decided by “what features you add.” It isn’t. It’s decided by which host that traffic is flying toward.
You can own the most impressive box (WAF, bot protection), but if the traffic you want to protect doesn’t pass through that box, it sails right past and that’s the end of it.
Cloudflare can stand at the front door. But which door the spam comes in is decided by the form’s implementation.
Even when you’re just fixing one form, look first at “when the submit button is pressed, where does that request fly?” Draw the architecture diagram after that.
I’m leaving this here as a note-to-self for almost writing a prescription on reflex. Next time someone asks you to stop form spam, open the Network tab in your dev tools first. That request — is it really reaching your server?