Cloudflare for ecommerce: rules every store should have

Cloudflare sits in front of most stores we run, and the default settings stop maybe half of what actually hits an online shop. The managed ruleset catches the obvious injection and scanner traffic. It does nothing about the stuff that is specific to commerce: someone running stolen cards through your checkout a hundred at a time, bots scraping your prices to undercut you by a dollar, credential stuffing against customer logins, fake accounts piling up to abuse a launch coupon. None of that looks malicious to a generic firewall. It looks like shopping.

So here are the custom WAF rules we set up on a store, why each one earns its slot, and the trade-offs. Free plan gives you five custom rules and five rate-limiting rules, which is tighter than it sounds, so we will be honest about which ones need Pro or Bot Management to do properly.

Edge rules protect the storefront, but the checkout has its own reliability layer. If you run Stripe, our notes on a production-grade OpenCart Stripe integration cover the webhook and 3D Secure gaps that quietly cost stores real orders.

Lock the admin and dashboard to addresses you trust

The single highest-value rule on any store is the dullest one. Your admin panel does not need to be reachable from Vietnam, or from a residential ISP in a country you do not ship to, or from the open internet at all if your team works from a couple of known locations. WordPress exposes /wp-login.php and /wp-admin; OpenCart hides its admin behind a custom folder but the login still answers to anyone who finds it.

The expression looks like this:

(http.request.uri.path contains "/wp-login.php" and not ip.src in {203.0.113.4 198.51.100.20}) → Block.

Swap in your office and home IPs. If your team is mobile and IPs change, downgrade Block to Managed Challenge so a human can still get through with a checkbox while a bot cannot. This one rule kills the entire category of login brute force before it touches PHP, which matters because every failed login on the origin still costs you CPU.

Rate-limit checkout and payment to stop card testing

Card testing is the attack most store owners have never heard of until their payment processor emails them about it. Someone has a list of stolen card numbers and needs to know which still work, so they script tiny authorisations against any checkout they can find. Your store becomes a free validation service, your authorisation rate craters, and your processor starts threatening to drop you over the decline ratio.

A normal customer hits your payment endpoint once, maybe twice if a card fails. Nobody legitimately submits payment fifteen times in two minutes. So we rate-limit the checkout and payment paths hard:

• Path contains /checkout or your payment callback route
• More than 8 requests in 1 minute from one IP
• Action: Managed Challenge, then Block if it continues

On OpenCart we rate-limit route=checkout and route=payment; on WooCommerce it is the /checkout/ page and the /?wc-ajax=checkout call, which the scripts hit directly to skip the page load. Watch that AJAX endpoint specifically, because that is where the volume lands.

Challenge customer login and account creation

Two related problems sit on the same pages. Credential stuffing is attackers replaying email and password pairs leaked from some other breach against your customer login, betting that people reuse passwords. Fake account creation is bots registering hundreds of accounts to farm signup discounts or launch coupons, or just to clog your database.

You do not want to block these outright, because a real customer might trip the rule on a bad day and a blocked customer is a lost sale. Managed Challenge is the right tool: invisible to most humans, a wall to scripts.

(http.request.uri.path contains "/my-account" or http.request.uri.path contains "register") and http.request.method eq "POST" → Managed Challenge.

We scope it to POST so people browsing their account page never see a challenge, only the actual login and registration submissions get checked. If you sell a launch and expect a registration spike, raise the threshold for that window rather than turning the rule off.

Slow down the price and inventory scrapers

If you compete on price, somebody is scraping you. Competitors run bots across your category and product pages to reprice against you in near real time, and the polite ones at least set a user agent. The cost to you is real: thousands of origin hits, skewed analytics, and your margins handed to a rival on a schedule.

Pure blocking is a losing game here because scrapers rotate IPs faster than you can list them. Two things help. Block the requests that are obviously not browsers, then rate-limit the rest:

(http.user_agent eq "" or cf.threat_score gt 14) on your product and category paths → Managed Challenge.

An empty user agent on a product page is never a customer. The threat-score threshold catches addresses Cloudflare already distrusts. This is where Bot Management, which is a paid add-on, genuinely pulls its weight: its bot score is far better than threat score at telling a headless scraper from a shopper, and on a Pro plan the Bot Fight Mode is a reasonable middle ground. On free, the empty-user-agent rule alone removes a surprising amount of junk.

Block the spam that rides in on POST requests

Contact forms, review submissions, coupon fields, newsletter signups: anything that accepts a POST is a target for the spam bots that crawl the web filling in every form they find. Most of them never load your page first, so they arrive with no referer and a blank or junk user agent.

(http.request.method eq "POST" and http.referer eq "" and not http.request.uri.path contains "/api") → Managed Challenge.

Mind the API exclusion. If your store has a mobile app or a headless frontend that posts to an API, those calls legitimately have no referer, so carve them out before you switch this on or you will break your own integrations. Test it in Log mode for a day first and read what it catches.

The order to turn these on

Do not enable all five at once on a live store. Cloudflare lets you set any rule to Log instead of Block or Challenge, which records what would have matched without touching live traffic. Run each new rule in Log for a day, read the matches in the Security Events view, confirm you are catching bots and not customers, then promote it. The admin lock and the checkout rate limit are the two we turn on first because they have the highest payoff and the lowest false-positive risk. The scraper and spam rules need a tuning pass before you trust them.

This is the edge layer of a wider job. The non-store baseline we start from is the five Cloudflare rules we add to every site. Cloudflare rules stop traffic before it reaches your server, but they do nothing for a plugin vulnerability or a weak admin password already sitting on the box, which is why we treat them as one piece of a full Cloudflare security setup rather than the whole answer. If your store runs on WordPress or OpenCart, the rules above pair with origin-side hardening we cover under our security services, and the same bots that test cards usually got your customer passwords from somewhere, which is its own recurring problem worth fixing at the source.

Want us to set this up and tune it against your real traffic? That is part of what we do on a Cloudflare hardening engagement for stores, and we leave you the rule export so you own it afterward.