ChatGPT
Perplexity
Claude
For a booking or payment platform, deploy Cloudflare WAF in this order: proxy DNS first, enable Cloudflare Managed Ruleset and the OWASP Core Rule Set in log mode for two weeks, then flip them to block. Add custom rules for credential stuffing, OTP abuse, coupon enumeration, and carding before you touch bot management. Rate-limit login, OTP, checkout, and payment endpoints individually, and exempt your payment provider’s webhook IPs explicitly. Everything else is detail.
Most setup guides treat Cloudflare WAF as a generic web property control. Booking and payment platforms have specific abuse patterns (rate-shopping, credential stuffing, OTP SMS-cost abuse, carding, coupon brute force) that managed rules alone do not catch. This guide covers the custom rules, the rate-limit thresholds, and the deployment order that actually work in production.
Why does the deployment order matter so much?
Because false positives are the only thing that can make this rollout fail. A WAF that blocks 95% of attacks and 0.5% of real customers is worse than no WAF at all if the 0.5% includes paying users at checkout. Every layer goes in with action set to log first, every layer gets calibrated against real traffic for one to two weeks, and only then does the action flip to block. Skip this step and you will spend the next month chasing tickets.
The recommended sequence for a booking or payment platform:
- DNS migration + proxy (orange-cloud) on all customer-facing hostnames
- Cloudflare Managed Ruleset in log mode
- OWASP Core Rule Set in log mode
- Custom rules in log mode
- Rate limiting in log mode
- Super Bot Fight Mode in challenge mode (less aggressive than block)
- Promote each layer to block after one to two weeks of clean logs
Steps 2 through 6 can overlap. Just do not flip anything to block until you have read its log output.
What managed rules should I enable first?
Two: Cloudflare’s own Managed Ruleset and the OWASP Core Rule Set. The Cloudflare set is maintained by their threat research team and covers known CVEs and signature-based attacks with low false-positive rates. OWASP covers the broader Top 10 (SQL injection, XSS, command injection, local file inclusion) with stricter signatures and a higher false-positive rate that needs tuning.
Enable both from the dashboard at Security > WAF. Action: log. Sensitivity: start at medium for OWASP and high for Cloudflare Managed. Read the Cloudflare Managed Ruleset reference for the full rule list.
Two weeks of log data will surface the false positives that matter. The common offenders for booking platforms:
- Admin and CMS save endpoints (false positives on long JSON payloads with quotes)
- Search endpoints (false positives on legitimate punctuation in city names)
- Payment callback URLs (false positives on encoded payloads from providers)
Tune those rules individually rather than dropping the whole ruleset.
Custom rules for booking and payment threats
Managed rules cannot see business logic. They do not know that your corporate portal should only be reachable from Saudi Arabia and a few GCC countries, that your CMS admin path should only be reachable from office IPs, or that your pricing API should reject requests with no Accept-Language header. Custom rules carry this layer.
The custom rules every booking and payment platform should ship:
Geo-restrict B2B corporate portals. If your corporate booking portal serves a fixed list of countries, block the rest at the edge. Expression example: (http.host eq "corporate.example.com") and not (ip.geoip.country in {"SA" "AE" "KW" "QA" "BH" "OM"}). Action: block.
IP-allow-list CMS admin. The admin path should only be reachable from your office, VPN, or jump host IPs. Expression: (http.request.uri.path contains "/admin") and not (ip.src in {1.2.3.0/24 5.6.7.0/24}). Action: block.
Block scraper user agents on pricing endpoints. Known headless browser fingerprints and scraper UA strings hit the pricing and search endpoints more than anywhere else. Expression: (http.request.uri.path contains "/api/pricing") and (http.user_agent contains "HeadlessChrome" or http.user_agent contains "PhantomJS"). Action: managed challenge.
Reject empty referrers on POSTs to booking and payment. Legitimate browsers send a referrer on form submissions. Empty referrers on booking and payment POSTs are almost always automation. Expression: (http.request.method eq "POST") and (http.request.uri.path in {"/api/booking" "/api/payment"}) and (http.referer eq ""). Action: block.
Block missing common browser headers on pricing API. Real browsers send Accept-Language, Accept-Encoding, and standard User-Agent strings. Scrapers often skip these. Expression: (http.request.uri.path eq "/api/pricing/search") and (not http.request.headers["accept-language"][0] matches "^[a-z]{2}"). Action: managed challenge.
Allow-list verified bots that matter. Before any of the above, allow-list Googlebot, Bingbot, and contracted OTA partners. Expression: cf.client.bot. Action: skip. Without this you will lose search rankings.
How should you set rate limits on checkout and payment endpoints?
Lower than you think. The standard rough budget for a booking and payment platform:
- Login: 5 failed attempts per IP per 10 minutes, then managed challenge. Per username: 10 failed attempts per hour, then block.
- OTP request: 3 per phone number per 5 minutes. 5 per IP per 5 minutes. This is the rule that protects your SMS bill.
- Password reset: 3 per account per hour. 10 per IP per hour.
- Booking creation: 20 per session per hour. Higher for authenticated B2B users.
- Payment API: 10 per session per 10 minutes. Anything higher is almost certainly automation or a confused integration.
- Coupon and gift-card apply: 10 per session per hour. This is your defence against enumeration.
These are starting points, not gospel. Tune against your own log data. Cloudflare’s rate limiting best practices doc walks through the expression syntax.
When should I exempt payment webhook IPs from rate limits?
Always, and explicitly. Payment providers (Stripe, Checkout.com, HyperPay, Tap, Mada) call your webhook endpoints back at unpredictable rates, especially during settlement windows. If you apply a generic IP-based rate limit to the webhook path, you will eventually drop a settlement callback and create a reconciliation problem.
The right pattern is a Skip rule at the top of the rate-limit list that matches the provider’s published IP ranges and the webhook path. Expression example: (http.request.uri.path eq "/api/webhooks/payment") and (ip.src in {payment_provider_cidrs}). Action: skip. Position: above all other rate limits.
Audit the provider’s IP list quarterly. They do change.
How long should I run in log mode before flipping to block?
Two weeks for managed rules, two weeks for custom rules, one to two weeks for rate limits, two weeks for Super Bot Fight Mode. Less than that and you have not seen the full weekly cycle: weekend traffic, payroll Tuesdays, marketing email Wednesdays, the monthly statement run. Each cycle surfaces a different class of false positive.
The exception is an active attack. If you are taking traffic that is clearly malicious right now, you flip to block immediately and triage false positives reactively. The two-week log period is for the calm rollout case, not the incident case.
Common mistakes to avoid
Putting bot management in front of WAF in the deploy order. Bot management is loud. If you turn it on before custom rules and rate limits are tuned, every false positive will look like a bot block, and you will lose trust in the score.
Forgetting to lock the origin firewall to Cloudflare IPs. Without this, an attacker who knows your origin IP from historical DNS records can bypass the entire edge. Restrict the origin firewall to Cloudflare’s published IP ranges after the proxy is enabled.
Setting OWASP CRS to “high” sensitivity on day one. It is too aggressive for booking traffic and will create a ticket avalanche. Start at medium, tune individual rules, then increase.
Using a single shared rate-limit rule for “all API endpoints”. Each endpoint has a different abuse profile. A unified limit is either too loose to stop OTP abuse or too tight for legitimate booking traffic. Per-endpoint rules.
Skipping the verified-bot allow-list. You will tank your search rankings within a month.
What this looks like in production
We documented the same control stack on a Saudi mobility platform behind Cloudflare: managed rules and OWASP CRS blocked over 4 million requests per month carrying recognised attack signatures, custom rules added another 6.5 million blocked requests on top, automated scraping reaching origin dropped from 38% of total traffic to under 3%, and OTP SMS abuse stopped within hours of the OTP rate limit shipping.
The same approach applies to any consumer or B2B booking platform: hotels, e-commerce, fintech, travel, healthcare appointments, anything with a login, an OTP, and a payment.
Need a Production-Grade Cloudflare WAF for Your Booking or Payment Platform?
Setting up Cloudflare WAF is fast. Tuning it without breaking checkout is the hard part. The custom rules, the rate-limit thresholds, the verified-bot allow-list, the payment-webhook exemptions, and the order in which everything gets promoted from log to block are what separate a deployment that survives peak traffic from one that creates customer support fires.
Tasrie IT Services provides comprehensive Cloudflare managed services to help you:
- Deploy WAF, bot management, and rate limiting correctly, with every layer tuned against your real traffic before blocking is enabled
- Write custom rules for booking and payment-specific abuse including credential stuffing, OTP cost abuse, coupon enumeration, and carding
- Hand over a documented configuration so your team can operate and tune the edge after we leave
Our broader cybersecurity services cover the full edge plus origin posture, and we run the same playbook for clients on AWS, Azure, and on-premise infrastructure.