Magento 2 Cloudflare WAF & Bot Protection Audit and Implementation
Rebuilt a leaky Cloudflare WAF across 7 zones, shut down active Magento CVE exploitation attempts, and cut bot traffic 70%.
March 2026/Australia/~3 weeks (M1 audit through M3 implementation)
StackMagento 2 (primary + duplicate storefronts) · AWS EC2 (ap-southeast-2) · Cloudflare Pro (main) + Free plan (6 sibling domains) · Nginx reverse proxy · MySQL
The situation
A Magento 2 store was getting hammered by bots from cloud ASNs like Azure, Tencent, and Alibaba, and was seeing active exploitation attempts against a known Magento file-upload CVE. The Cloudflare rules already in place were partly working. The main crawler-blocking rule had a 98% bypass rate, a duplicate storefront had no protection at all, and the origin IPs were sitting in DNS, unproxied, for anyone to find.
What I found
There was active exploitation going on. Attackers were hitting /customer/address_file/upload (CVE-2025-54236) and probing for the webshell filename bf7721e2f928.php. A CVE-2019-7816 ColdFusion vulnerability probe also showed up in the logs. 39.6% of firewall events in the last 14 days (11,864 out of 29,991) were sourced from Microsoft Azure, with Tencent Cloud scraping distributed across Singapore, Japan, Hong Kong, and Germany, and an Alibaba Cloud distributed crawler at 211 requests from ALIBABA-CN-NET.
The Cloudflare rules themselves were letting most of this through. The crawler-block rule had a 98% bypass rate, because Barkrowler, PetalBot, and Baiduspider were being waved through by an earlier verified-bot rule. That verified-bot rule used 'allow' instead of 'skip', so it was bypassing the managed WAF and OWASP rules entirely. A geo-allow rule for India was passing 15,970 events in 24 hours around every security rule. And ASN 396507 (AMBYRE LLC), a confirmed REST API attacker, wasn't on the crawler block at all.
Protection coverage was uneven across the 7 zones. A duplicate Magento storefront was live with zero custom firewall rules and had already taken 6,833 unprotected events. 4 additional sibling domains on the Cloudflare Free plan had no custom protection either. Origin IPs were exposed through unproxied DNS records on staging and legacy www subdomains, and the staging subdomain was pointed at a third-party dev agency, also unproxied.
The REST API was wide open. /rest/V1/guest-carts and /rest/V1/directory/countries were fully unauthenticated. Meanwhile, verified bots had been rate-limited to 5 req/60s, which cut Googlebot to about 5 pages a minute and dropped mobile crawl 38% across 11,739 rate-limit hits. CORS was misconfigured with Access-Control-Allow-Origin '*' combined with credentials: true, TLS 1.0 and 1.1 were still enabled (RFC 8996 deprecated), and 8 security headers were missing (CSP, Referrer-Policy, Permissions-Policy, COEP, COOP, CORP, and a couple of others).
What I did
I ran a read-only Cloudflare API audit across all 7 zones and captured 186 JSON config artefacts. Then I pulled 14 days of historical firewall events (29,991 total), plus a 24-hour unsampled pull (36,249 events) to baseline normal traffic, and correlated attacker IPs across the zones, 6,887 unique sources with 54 appearing on multiple domains. DNS enumeration mapped all the origin IPs and unproxied records, and a Nuclei scan turned up 37 vulnerability findings.
Each zone got 10 custom Cloudflare rules. The core ones were a PHP webshell path lockdown on /media/, ASN blocks (Alibaba 45102, Tencent 132203, HOSTKEY 57043, RADISHCLOUD 201217, NVIDIA-NET 23028, BYTEPLUS 134771), and endpoint lockdowns on /media/custom_options/, /pub/media/, and /customer/address_file/upload. I deployed a user-agent block list covering python-requests, Windows NT 5.1, macOS 10_9_3, and Firefox/72.0, all deprecated or spoofed. I also implemented REST API rate-limit rules on /rest/V1/guest-carts.
The existing verified-bot rule got corrected from 'allow' to 'skip' so real managed-WAF and OWASP coverage came back online. On top of that I added a Managed Challenge for traffic outside AU, US, GB, and NZ, with a verified-bot exemption so Googlebot and friends still get through cleanly. Finally, I wrote up a set of origin-IP-hiding recommendations for the unproxied DNS records.
How it landed
Once the new rules went live, every identified attack pattern got blocked at the edge. Webshell probes against /customer/address_file/upload started returning 403 via the python-requests UA rule. Tencent scrapers got 403 or a managed challenge. Bot volume dropped 70%: the primary zone went from 22,000 Cloudflare requests/day down to about 186 real-user requests/day. The geolocation rule filtered 35% of suspicious traffic in a 24-hour window, 1,920 hard blocks and 1,020 challenged. The crawler-block rule that had been bypassed 98% of the time actually started working once the verified-bot logic was put in the right order.
In their words
“Tanveer delivered an outstanding security audit that went well above and beyond the scope of the engagement. He analysed over 66,000 firewall events across all 7 of our domains, identified active exploitation attempts we were not aware of, and delivered a detailed, evidence-backed report with clear recommendations. His communication was excellent throughout and his technical knowledge of Cloudflare WAF is first class. The M2 implementation plan he produced is thorough and ready to execute. I would not hesitate to rehire Tanveer for future security work and highly recommend him to anyone needing serious Cloudflare WAF expertise.”