Integrations
Cloudflare WAF and Mews: nine rules that kill bookings
Your booking pace was tracking. Then Cloudflare ate four out of every five chats. A field guide to the nine WAF rules that go quiet at exactly the wrong moment.
Friday, 23:14. The on-duty revenue manager at a 47-room boutique in Utrecht checks the dashboard. Booking pace was tracking last weekend at noon. Since 17:00 it has gone flat, and the chat widget on the property site has been spinning since happy hour. Booking.com fired a discounted-stays email at 16:30. Three hundred guests opened it. About forty tried the chat. Sixteen made it as far as a date picker. Three got a response from the agent.
The other thirty-seven hit a Cloudflare rule. Nobody saw a clean error. The widget just sat there.
This is the field guide we wish we had when we built our first Mews-backed hotel agent in 2023. Nine WAF rules to audit before your next OTA traffic spike, ordered by how long it takes the revenue manager to notice the bleeding. The first ones on the list will not raise an alarm until Monday’s pace report. The last ones will get a guest tweet inside an hour.
The five surfaces nobody draws on the architecture diagram
A hotel chat agent on Mews and Booking.com touches more network surfaces than the architecture diagram usually shows. There is the guest-facing widget, of course. There is also the Mews Connector API that your agent calls to read property state. There are Mews webhooks pushing reservation changes into your stack. There is the Booking.com Messaging API delivering OTA guest chats. There is the outbound call from your agent to its LLM provider.
Most teams put Cloudflare in front of the widget and call it done. The other four surfaces behave nothing like browsers. They do not run JavaScript. They do not retry forever. They fail in ways that the Cloudflare event log labels as “challenge served” instead of “request blocked.” By Monday morning, half of the failures have rotated out of the free-plan 24-hour log window.
The nine rules, ordered by stealth
The order matters. Rule one is the one your revenue manager will only spot because Monday’s pace looks soft for no obvious reason. Rule nine is the one that will get a complaint in your inbox by Saturday brunch.
1. AI Crawlers managed ruleset blocking your own outbound calls
Cloudflare shipped an AI bots managed rule that blocks traffic identifying as ChatGPT-User, Claude-Web, GPT-Bot, and friends. If your chat agent runs on a Worker and calls an LLM with the SDK’s default User-Agent, the rule can match your own egress. The agent times out. The user sees “Sorry, something went wrong.” You will never find this in the WAF log of your own zone because the block happens on the upstream side, not on ingress to your domain.
2. User-Agent block on the Mews Connector API
Mews calls your webhook receiver with a User-Agent like Mews/2024.10. Several managed rulesets flag short or version-only UAs as suspicious. Your endpoint returns 403. Mews retries three times, then drops the event. Front desk opens the arrivals tab Monday morning and sees twelve guests they did not know were coming. There is no widget error to complain about. There is no Slack alert. The PMS just has gaps.
3. SQL injection rule on guest names with apostrophes
A guest named Marie O’Brien types “Hi, can I check in at 23:00?” into the widget. The apostrophe in her name (passed in the session metadata) matches OWASP rule 942100. Cloudflare returns 403. Your agent never sees the message. The widget shows the spinner forever. Marie books on Booking.com instead. You pay 17 percent commission for a guest who tried to come direct.
4. JS Challenge on the webhook path
A blanket “Challenge anything that looks automated on /api/*” rule will eat your Mews webhook receiver. Mews sends a POST with a JSON body. Cloudflare returns an HTML page asking for JavaScript evaluation. Mews’s HTTP client cannot evaluate JavaScript. The signature check on your end will not even run because the body is now HTML. After three failures, Mews backs off the endpoint. You stop receiving reservation updates until you redeploy.
5. Bot Fight Mode catching Booking.com webhooks
Bot Fight Mode is the one-click switch in the free dashboard. It blocks anything without a browser fingerprint. Booking.com’s webhook calls have no browser fingerprint. The block is fast and quiet: a 403 with no body. Your messaging integration goes dark for the busiest two hours of the night, then recovers when the OTA’s retry queue clears.
6. OWASP CRS 949110, the inbound anomaly threshold
The Cloudflare OWASP Core Ruleset assigns a score to each match and blocks at the threshold. A guest pastes a long question with a URL, a date range, and a price comparison. The cumulative score crosses 949110 and the request is 403’d. The agent gets nothing. The guest assumes the bot is broken and books on the OTA. This rule disproportionately hits real intent-to-book messages because they tend to be longer and contain numbers.
7. Country block hitting your night staff and VPN guests
You blocked a country after a brute-force attempt last spring. The Filipino night auditor working from her apartment in Cebu cannot open the back-of-house dashboard. The German guest who uses a US-routed VPN to read the news cannot open the chat widget. You will discover this only when staff complains, which on a quiet Friday night may take six hours.
8. Managed Challenge on /api/* paths
Cloudflare’s Managed Challenge mode catches anything that does not look like a real browser. The Mews mobile staff app uses a WebView with a non-standard UA in some builds. Housekeeping cannot mark rooms clean. Front desk cannot edit reservations. The widget on the public site keeps working, so nobody escalates until housekeeping radios down.
9. Rate limiting on POST to the chat endpoint
The loudest one. Default rate-limit rules (“10 requests per 10 seconds per IP”) interact badly with corporate networks where 30 guests are behind one NAT. When the Booking.com email lands and traffic from a hotel-chain HQ network spikes, the first guest gets through. The next twenty get 429s. The widget shows “Try again later.” This is the rule the revenue manager will hear about, because guests complain on social media.
Free-plan Cloudflare keeps WAF events for 24 hours. If your pace report runs on Monday and the surge happened Friday, the evidence is already gone. Pipe events to your own log store before you go hunting.
The twenty-minute audit you can run before checkout
You do not need to migrate off Cloudflare to fix this. You need to know which rules are firing on which paths.
First, send a webhook-shaped request to your own endpoint, from outside your office network:
curl -X POST https://yourdomain.com/webhooks/mews \
-H "Content-Type: application/json" \
-H "User-Agent: Mews/2024.10" \
-d '{"event":"reservation.modified","reservationId":"test-001"}' \
-w "\nHTTP %{http_code} in %{time_total}s\n"
A 200 means the path is clear. A 403 or 503 means a rule is in the way. An HTML body means a challenge.
Second, in the Cloudflare dashboard, filter Security Events by the hostname your webhook lives on, with action “block” or “challenge,” over the last 24 hours. Sort by rule. The top three rules are your top three suspects.
Third, write a configuration rule (under Security in the new dashboard) that disables Bot Fight, Browser Integrity Check, and Managed Challenges on the exact paths your server-to-server traffic uses: /webhooks/*, /api/internal/*, and any callback paths your OTA integrations need. Whitelist Mews and Booking.com IP ranges if you can get them. Sign every webhook so disabling the challenge does not lower your real security floor.
What we tell hotel clients to do next
The instinct after reading a list like this is to disable everything. Do not. The WAF is doing useful work on the widget path. The fix is path-specific configuration, not a security retreat.
When we built the chat agent for a Dutch hotel group with seven properties on Mews, the rule that bit us hardest was number two on this list. Mews’s User-Agent looked enough like a scanner that the default managed ruleset 403’d every webhook for ten days before we noticed. We ended up routing all server-to-server traffic through a dedicated subdomain with its own (much smaller) ruleset, and putting an in-house request logger in front of the WAF so we could see blocks without waiting on Cloudflare’s log retention. If you are building or operating AI agents on top of a PMS, audit the integration paths first. The customer-facing widget is rarely where the booking is actually lost.
Pull up your Cloudflare Security Events tab now. Filter by webhook hostname, last 24 hours, action equals block. If there are any rows, you have your weekend reading.
Key takeaway
The Cloudflare rule that costs you bookings is rarely on the widget path. It is on the webhook your PMS uses to tell you the reservation changed.
FAQ
Will turning off Cloudflare Bot Fight Mode expose me to attacks?
Not if you disable it only on the specific server-to-server paths your PMS and OTA use, and keep it active on the guest-facing widget. Path-scoped rules are the answer.
How do I get Mews and Booking.com IPs to whitelist?
Mews publishes outbound IP ranges to enterprise customers on request. Booking.com partners can ask their account manager. Without ranges, lock down by User-Agent plus signed payload instead.
Does the AI Crawlers ruleset block Claude or ChatGPT API calls?
It can match outbound traffic from Workers if the SDK sends a default User-Agent that looks like a known crawler. Set an explicit, descriptive UA on your LLM client and it usually passes.
Where do I see Cloudflare WAF events older than 24 hours?
You need a paid plan (Pro and up extend retention) or you forward events to your own log store via Cloudflare Logpush. Plan for this before you need it, not after.