A Saudi mobility platform engaged Tasrie IT Services to put a production-grade security and performance edge in front of its booking platform, CMS, and payment APIs. Six weeks later the platform was blocking over 12 million malicious requests per month, mitigating Layer 7 DDoS attempts automatically, and serving pages roughly four times faster from Cloudflare’s edge. Client identity is withheld under NDA.
Client Background
The client operates a consumer mobility platform with a national footprint across the Kingdom of Saudi Arabia and a digital channel that serves both B2C consumers (short and medium-term bookings through the website and mobile app) and B2B corporate customers (long-term contracts, fleet usage, and corporate booking portals). Their stack covers a public marketing site, a CMS-backed booking system, a customer account area, a corporate booking portal, payment APIs integrated with Saudi payment processors, and a set of internal APIs used by operational staff.
Before this engagement, all of those properties resolved directly to their origin infrastructure. There was no WAF in front of the origin, no rate limiting on the login or payment APIs, and no bot management. DNS was hosted with a regional provider with no proxy capability.
The Problem
The security team flagged four converging risks ahead of the December 2025 peak season.
1. Constant scraping of pricing and availability. Consumer mobility platforms are one of the most aggressively scraped categories on the public web. Rate-shopping bots run by competitors and aggregators pull pricing, availability windows, service tier, pickup and drop-off locations, and supplier identifiers on continuous schedules. The client’s analytics showed clear signatures: very high request rates against the search and listing endpoints from a small number of ASNs, traffic patterns that did not match human session behaviour, and revenue impact when competitors undercut prices within minutes of a change.
2. Credential stuffing and OTP abuse. The customer login endpoint, password reset, and OTP request endpoints were being hit by botnets running credential-stuffing attacks. Without rate limits the OTP SMS gateway was occasionally being abused to send hundreds of messages an hour, generating real cost and risking account takeover on B2C accounts that store stored payment instruments.
3. Layer 7 DDoS exposure in the highest-risk region. Saudi Arabia recorded the highest DDoS attack volume in the MENA region in H1 2025, with over 270,000 attacks observed, and MENA application-layer attacks surged 236% year-on-year. The client had already taken one Layer 7 HTTP flood that knocked the booking portal offline for several hours earlier in the year. With Riyadh Season and winter travel demand approaching, another incident during peak booking traffic was not acceptable.
4. Payment and booking APIs had no abuse controls. The payment and booking endpoints accepted unauthenticated requests for a short window during the checkout flow. Without rate limiting they were exposed to gift-card enumeration, coupon-code brute force, and booking-form abuse that consumed inventory holds without converting.
The brief was simple: get every customer-facing hostname behind Cloudflare, block the obvious threats, slow down the abusive traffic, and harden the booking and payment APIs without breaking conversion.
What We Deployed
The engagement ran for six weeks with a team of two Tasrie IT Services consultants working alongside the client’s security lead and platform engineer. Below is what each control does, why we put it in, and what it changed.
1. DNS Onboarding, Migration, and Proxy Configuration
What it is. Cloudflare became the authoritative DNS provider for all customer-facing zones. Every customer-facing A and CNAME record was switched to proxied mode (the “orange cloud”) so traffic flows through Cloudflare’s edge before reaching origin.
Why we deployed it. Without proxied DNS, none of the rest works. Cloudflare’s WAF, bot management, DDoS protection, and CDN can only act on traffic that actually traverses Cloudflare’s network. Proxied DNS also hides the origin IP, which prevents attackers from bypassing the edge and hitting the origin directly.
How it helped. The origin IP is no longer exposed in public DNS responses. We tested this by attempting direct-to-origin requests using historical IP records and confirmed they were blocked at the origin firewall (which we tightened to only accept traffic from Cloudflare’s IP ranges).
2. WAF Managed Rules (Cloudflare Managed + OWASP Core Rule Set)
What it is. Two pre-built rule packages: Cloudflare’s own Managed Ruleset, maintained by their threat research team and updated as new exploits emerge, and the OWASP ModSecurity Core Rule Set, the industry-standard signature pack covering the OWASP Top 10.
Why we deployed it. Most automated attack traffic uses well-known signatures: SQL injection probes, cross-site scripting payloads, command injection, local file inclusion, and known CVE exploit attempts. There is no reason to handle this traffic at the origin when Cloudflare can drop it at the edge with rules vetted globally.
How it helped. In the first 30 days the Managed Ruleset alone blocked over 4.2 million requests carrying recognised attack signatures, including thousands of attempts to probe for vulnerabilities in the CMS admin paths. We tuned the OWASP rules to “log” mode for two weeks before flipping them to “block”, which avoided false positives on legitimate admin and finance traffic.
3. WAF Custom Rules
What it is. Bespoke firewall expressions written for this client’s specific traffic patterns. Managed rules cannot know which countries are allowed to access the corporate booking API, which user-agents are known scrapers, or which paths should reject empty referrers.
Why we deployed it. A managed rule cannot see that the corporate B2B booking portal should only be reachable from Saudi Arabia and a small set of allow-listed GCC countries. It cannot see that the CMS admin path should only be reachable from the client’s office IP ranges. It cannot see that requests to the pricing API with no Accept-Language header and a User-Agent matching headless Chromium are almost certainly scrapers.
How it helped. The custom rules carry most of the business-logic protection. Examples we shipped:
- Geo-restrict the corporate B2B portal to allowed countries.
- IP-allow-list the CMS admin path to office and VPN ranges.
- Block requests to the public pricing API with missing common browser headers.
- Block known scraper user-agent strings and headless browser fingerprints from product and pricing endpoints, while explicitly allowing Googlebot, Bingbot, and contracted OTA crawlers.
- Reject empty-referrer POSTs to the booking and payment endpoints.
Together the custom rules added another 6.5 million blocked requests per month on top of the managed rules.
4. Super Bot Fight Mode
What it is. Cloudflare’s machine-learning-based bot scoring engine. It classifies every request into verified bot, likely automated, likely human, or definitely automated, using behavioural signals, fingerprinting, and Cloudflare’s network-wide intelligence.
Why we deployed it. Consumer mobility pricing is one of the most actively scraped categories on the public web. The client’s analytics had already shown that roughly 38% of pre-Cloudflare traffic was non-human. Plain IP rate limits do not work against modern scraper infrastructure that rotates through tens of thousands of residential proxies. We needed behavioural detection that can spot a botnet even when each individual IP only sends a few requests per minute.
How it helped. We tuned Super Bot Fight Mode to challenge “likely automated” traffic with a managed challenge and outright block “definitely automated” traffic. We then added an explicit allow-list for verified bots that matter to the business (search engines, contracted OTA partners). Within two weeks the share of automated traffic actually reaching origin dropped from roughly 38% to under 3%. Origin CPU usage on the listing pages dropped accordingly, and the price-shopping signals competitors had been getting in near real time degraded sharply.
5. Layer 7 DDoS Protection
What it is. Application-layer DDoS mitigation that profiles request patterns at the edge and automatically blocks volumetric HTTP and HTTPS floods. This is distinct from the network-layer DDoS protection that ships with every Cloudflare zone.
Why we deployed it. Saudi Arabia was the most attacked country in MENA in 2025, with the region’s application-layer attacks up 236% year-on-year. Most of these attacks now sit under the 100,000 requests-per-second threshold; they are smaller and more persistent rather than headline-grabbing terabit floods. A consumer booking platform is a viable target during peak season because every minute offline is direct revenue loss.
How it helped. In the first 90 days the platform absorbed six L7 DDoS attempts without paging the security team and without measurable customer impact. The largest peaked at 84,000 requests per second against the booking search endpoint. Cloudflare’s L7 ruleset auto-mitigated the attack within seconds based on the request anomaly profile. The client’s incident channel went from “all hands” during the pre-engagement attack to “logged and reviewed the next morning”.
6. Rate Limiting
What it is. Per-IP, per-session, and per-token request budgets applied to specific endpoints. Cloudflare’s Rate Limiting evaluates the count of requests over a sliding window and applies an action (block, challenge, log) when a threshold is exceeded.
Why we deployed it. Some abuse patterns look like legitimate traffic to the WAF, because each individual request is well-formed. Credential stuffing is just lots of valid login attempts. OTP flooding is just lots of valid OTP requests. Coupon enumeration is just lots of valid checkout calls with different coupon codes. The only effective control is a request budget.
How it helped. We shipped specific rate limits on:
- Login: capped failed attempts per IP and per username before challenging.
- OTP request: capped per phone number and per IP to stop SMS-cost abuse.
- Password reset: capped per account and per IP.
- Booking creation: capped per session to prevent inventory-hold abuse.
- Coupon and gift-card application: capped per session and per IP to stop enumeration.
- Payment API: capped to expected per-session call counts.
These rules trigger roughly 250,000 rate-limit actions per month, almost all of them against automated abuse traffic. OTP SMS costs dropped meaningfully after the OTP rate limit shipped.
7. CDN and Performance Optimization
What it is. Edge caching of static and cacheable dynamic content, Brotli compression, HTTP/3 with 0-RTT resumption, image optimization, and minification of CSS, JavaScript, and HTML.
Why we deployed it. Security at the edge is only half the value of putting a platform behind Cloudflare. The same edge that blocks attacks also serves cached responses, which means faster pages for customers and less load on the origin. Saudi Arabia has strong Cloudflare presence in Riyadh and Jeddah, so edge cache hits return in single-digit milliseconds for most users.
How it helped. Cache hit ratio settled at around 78% across static assets and cacheable listing pages. Median TTFB dropped from 380ms to 95ms. Origin bandwidth fell by 62%. The booking pages now render the above-the-fold content noticeably faster on the mobile networks most of the client’s traffic comes from, which matters for conversion and matters for Google’s mobile rankings.
8. Documentation and Configuration Report
What it is. A written deliverable covering the architecture, every WAF rule and the rationale for it, the rate-limit thresholds and how they were derived, the bot management posture, the DNS migration record, and an operational runbook for common scenarios (false positive triage, attack-in-progress response, rule changes).
Why we deployed it. The client team has to operate this configuration after we leave. A configuration that only the consultants understand is a configuration that decays. The rationale matters as much as the rules themselves, because the rules will need to be tuned over time as traffic and threats evolve.
How it helped. The client’s security and platform teams now have a single document that explains why every control exists. When a new false positive comes up they can trace it back to the rule that caused it, see the original intent, and decide whether to refine the rule or accept the block. Without that context they would be reverse-engineering their own production environment.
9. Knowledge Transfer Session
What it is. A working session with the client’s security lead, platform engineer, and SOC analyst. We walked through the Cloudflare dashboard, the WAF events log, the bot analytics, the rate-limiting analytics, and the runbook. We ran live drills: triaging a synthetic false positive, responding to a simulated attack, and changing a rule safely.
Why we deployed it. A handover document is a starting point. A team that has actually clicked through the dashboard during a drill is much more likely to respond correctly when something real happens.
How it helped. Within two weeks of go-live the client’s team raised their own first false-positive ticket, triaged it themselves using the runbook, and shipped the rule refinement without our involvement. That is the outcome we were looking for.
Results
Threats blocked. Over 12 million malicious requests per month are now dropped at the edge across managed rules, custom rules, bot management, and rate limiting. None of that traffic reaches origin.
Bot traffic reduction. Automated traffic reaching origin fell from roughly 38% of total requests to under 3%. The pricing and availability data that competitors used to scrape in near real time is now far harder to harvest at scale.
DDoS mitigation. Six Layer 7 DDoS attempts in the first 90 days, all auto-mitigated. The largest peaked at 84,000 requests per second, consistent with the smaller-but-persistent attack pattern that now dominates MENA. No customer-visible impact on any of them.
Performance. Median TTFB improved from 380ms to 95ms, CDN cache hit ratio settled around 78%, and origin bandwidth dropped by 62%. The booking and listing pages are noticeably faster on Saudi mobile networks.
Uptime. 100% uptime through the December 2025 go-live and the subsequent peak travel period, including Riyadh Season.
Operational handover. The client’s team operates the configuration without our involvement. They have raised and resolved their own rule refinements and false-positive triage tickets using the runbook.
Why This Engagement Worked
Three things mattered.
Tuning before blocking. Every layer (WAF, bot management, rate limiting) ran in log-only mode for one to two weeks before being flipped to block. False positives surfaced against real traffic instead of against test traffic, which is the only way to find them. By the time blocking was enabled, the rules had been calibrated against the client’s actual user behaviour.
Custom rules carried the business logic. Managed rules are necessary but not sufficient. The biggest single source of blocked traffic in the first month came from custom rules tailored to this client: scraper user-agent blocks on pricing endpoints, geo restrictions on the B2B portal, IP allow-lists on admin paths. None of those would have come from a managed ruleset.
Handover was treated as a deliverable, not an afterthought. The configuration report and the live KT session are the reason the client’s team can operate this independently. A Cloudflare engagement that leaves the client unable to maintain its own edge is a worse engagement, even if the rules are good.
About the Engagement
- Duration: 6 weeks from kickoff to handover
- Team: 2 Tasrie IT Services consultants plus the client’s security lead and platform engineer
- Go-live: December 2025
- Scope: All customer-facing properties including marketing site, CMS-backed booking platform, customer account area, B2B corporate portal, and payment APIs
- Confidentiality: Client identity is withheld under NDA
Need a Cloudflare Edge for Your Booking or Payment Platform?
If you run a booking, e-commerce, or payment platform in Saudi Arabia, the Gulf, or anywhere that sees high scraping pressure and Layer 7 DDoS risk, putting Cloudflare in front of your stack is one of the highest-leverage security and performance changes you can make. The hard part is the tuning, the custom rules, and the handover.
Our team provides comprehensive cybersecurity services to help you:
- Deploy Cloudflare WAF correctly, with managed rules and custom rules tuned to your traffic before blocking is enabled
- Stop scraper and credential-stuffing abuse on pricing, login, OTP, and payment endpoints with the right combination of bot management and rate limiting
- Mitigate Layer 7 DDoS with sensitivity tuned per hostname and a documented incident playbook your team can actually run
We deliver every engagement with a written configuration report and a knowledge-transfer session so your team can operate the edge independently after we leave.
Talk to our security team about your Cloudflare deployment →