Simon Willison documented a fix this week for a Cloudflare Web Application Firewall (WAF) rule that was triggering CAPTCHA challenges on nearly every search query on his site. The default bot-protection rule treated all search URLs as suspicious. Legitimate readers hit friction on every lookup. The fix was not a new CDN tier or a migration — it was narrowing the rule to match only URLs containing an ampersand, which correlates with multi-parameter queries that aggressive crawlers tend to generate.
The story is small. The lessons generalize: security defaults often over-block real users, and the fastest fix is usually a tighter rule — not more infrastructure.
Why default WAF rules over-block
Cloudflare's managed bot rules optimize for catching automated traffic. Search endpoints are a common attack surface: SQL injection probes, parameter fuzzing, and scraper floods all target query strings. A broad rule that challenges any request to /search catches bots — and also catches a human typing a single keyword.
Think of it like airport security screening every passenger because one gate had a incident last month. The policy is defensible in the abstract. The queue at peak hour tells you it is wrong for your traffic shape.
The symptom is familiar: users complain about CAPTCHAs on normal browsing, support tickets spike, and analytics show drop-off at the search box. The underlying issue is a rule scoped to the path, not to the signal that distinguishes bots from humans in your specific application.
The ampersand heuristic
Willison's adjustment changed the match condition from "any search URL" to "search URLs containing &". Single-parameter searches (?q=python) pass through. Multi-parameter requests (?q=python&sort=date) still trigger the challenge.
The heuristic rests on a simple observation: legitimate users on a personal site rarely construct complex multi-filter searches. Aggressive crawlers and injection tools often do. One character in the match pattern shifted the false-positive rate without removing protection on the traffic shape that actually looked automated.
A WAF rule should encode a hypothesis about what is malicious in your traffic — not a blanket distrust of an entire endpoint.
This is not universal advice. A site with heavy faceted search would need a different signal. The pattern to internalize is: start from observed bot behavior, write a rule that targets that behavior, measure false positives, iterate.
When MCP is the wrong tool
Willison attempted the fix through Cloudflare's Model Context Protocol (MCP) integration first. MCP exposes Cloudflare APIs to coding agents — a sensible first move when you already live in Claude Code. In this case, the MCP server could read rules but could not edit the specific custom rule configuration needed. The agent switched to direct API calls and completed the change.
That sequence is worth remembering. MCP is a convenience layer for agent-to-service communication. It is not a guarantee that every API surface is exposed. When an agent hits a capability gap, falling back to the underlying API — or the dashboard — is faster than forcing the protocol to do something it was not wired for.
| Approach | Good for | Watch out for |
|---|---|---|
| Dashboard edit | One-off rule tweaks, visual diff | Not scriptable, no audit trail in git |
| Direct API | Full CRUD on rules, automatable | Requires auth setup, easy to misconfigure |
| MCP via agent | Exploratory changes from a coding session | Capability coverage varies by server implementation |
Measuring after the change
Any WAF adjustment should be followed by a before/after check. Compare challenge rates on the affected path, watch error logs for injection attempts that now slip through, and spot-check legitimate user flows. Willison's change reduced friction on single-parameter searches while preserving challenges on multi-parameter traffic — a trade-off he can revisit if crawler patterns shift.
Security tuning is a loop, not a one-time configuration. Bot behavior adapts. Your rules should too.
What this means for builders
Audit managed rules before accepting defaults. Cloudflare, AWS WAF, and similar products ship with sensible starting points that may not match your traffic. A fifteen-minute review of which paths trigger challenges often finds obvious false positives.
Write rules as testable hypotheses. "Block search URLs with ampersands" is falsifiable — you can measure how many real users hit it. "Block all search" is not; you only notice when users leave.
Know your agent tool limits. MCP servers vary in what they expose. Keep API credentials and dashboard access as fallbacks when the agent reports it cannot complete an operation.
Prefer surgical rules over blanket protection. Narrow matches reduce user friction and make incident response easier — you know exactly what you changed when something breaks.
Conclusion
Infrastructure problems get expensive solutions. Configuration problems get cheap ones. Willison's CAPTCHA issue was the second kind: one character in a WAF match pattern restored normal search behavior for real users while keeping bot protection on the traffic that actually looked automated. The tooling story — MCP first, direct API when MCP fell short — is equally practical for anyone wiring agents into production infra.