PrestaShop Bot Protection: Cloudflare Rules That Don't Block Customers or Payments

PrestaShop bot protection is a set of rules that stops credential stuffing, fake registrations and vulnerability scanners before they reach PHP, while still letting shoppers, payment gateway callbacks and monitoring through. For a small or mid-sized store, the cheapest setup that works is Cloudflare Free: 5 custom rules and 1 rate limiting rule. Below is the exact layout I use at IThandy for PrestaShop 1.7, 8 and 9 stores, including how I allow my own monitoring bot, IThandy-Checker.

Which bots hit a PrestaShop store

The bots you will see most on a PrestaShop store test stolen passwords, create fake accounts, scrape prices and probe modules for known vulnerabilities. According to the Imperva Bad Bot Report 2025, bad bots made up 37% of all internet traffic in 2024, up from 32% a year earlier, and retail was the second hardest-hit industry (Malwarebytes on the Imperva report).

The usual suspects in store logs:

• Credential stuffing - automated login attempts with email and password pairs from data breaches. On one store I look after I counted 52 thousand requests to the login page in 12 hours. Imperva reports around 330 thousand account takeover incidents in December 2024, up from around 190 thousand in December 2023.
• Fake accounts and form spam - scripted registrations, newsletter sign-ups and contact form submissions that pollute your customer list and hurt email deliverability.
• Vulnerability scanners - looking for /.env, /.git, leftover install folders and vulnerable modules. Security advisories for PrestaShop modules are published by Friends of Presta.
• Scrapers - copying prices and descriptions, hammering category pages and search.
• Cart and card-testing bots - adding products to carts or trying stolen cards at checkout.

Then there are bots you must not block: Googlebot and Bingbot, payment gateway callbacks (PayPal, Stripe, Mollie and others), ERP and marketplace connectors, product feed fetchers such as Google Merchant Center, and your uptime monitoring. Most firewall problems I fix are a good bot that got blocked, not a bad bot that got through.

Layers of protection: from hosting to Cloudflare

A bot can be stopped in four places: at Cloudflare, at your host's firewall, in a PrestaShop module and in PHP itself. The earlier, the cheaper for your server, but every layer can also stop a real customer or a payment callback.

Hosting is the layer that surprises people. On ithandy.pl, a hosting WAF rule throttled bots by User-Agent from the 2nd or 3rd request, and nothing in the hosting panel mentioned it. Before touching any firewall setting, I ask the host what runs on their side.

PrestaShop Cloudflare rules on the Free plan

The Free plan gives you 5 custom rules, so each one needs a clear job. Order matters: the allow rule first, then back office protection, then blocks and challenges.

This is how I lay out the slots:

1. 00-allow (Skip action, first position). Lets through traffic that must never be challenged: monitoring, payment callbacks and integrations. PrestaShop modules receive callbacks through module front controllers, i.e. /module/<module-name>/<controller> with friendly URLs or index.php?fc=module&module=<name> without them. Check the exact path in your payment module's documentation.
2. 10-admin. Protects the back office. Your PrestaShop admin folder has a custom, random name (for example admin123abc) - use yours. Action: Block for anything outside your IP list, or Managed Challenge if you work from changing networks.
3. 20-scanners (Block). Cuts off scanners looking for files that should not exist on a store: /.env, /.git, /wp-login.php, /xmlrpc.php, /phpinfo.php, /install.
4. 30-auth-query (Managed Challenge). With friendly URLs on, real customers never see index.php?controller=authentication, controller=registration or controller=password. Bots use these variants because they slip past limits set on the friendly paths.
5. Spare slot. Keep it for incidents, for example a challenge on registration from countries you don't ship to.

Example for 30-auth-query:

(http.request.uri.path eq "/index.php"
 and (http.request.uri.query contains "controller=authentication"
   or http.request.uri.query contains "controller=registration"
   or http.request.uri.query contains "controller=password"))

Example for 10-admin (replace the folder name and IP):

(http.request.uri.path contains "/your-admin-folder"
 and not ip.src in {203.0.113.10})

A separate warning about caching: do not enable "Cache Everything" without bypass rules for the back office, cart, checkout and customer account, or shoppers may see other people's carts and personal data (mypresta.rocks: Cloudflare with PrestaShop).

Rate limiting PrestaShop login and registration

One rate limiting rule on Cloudflare Free is enough to slow down credential stuffing: it counts requests per IP over a 10-second window and blocks for 10 seconds. On Free the rule can only match the Path and the Verified Bot flag, so you protect the friendly URLs here and catch the controller= variants with the custom rule above (Cloudflare rate limiting docs).

Example for a store with English and Polish URLs:

(http.request.uri.path in {"/login" "/registration" "/password-recovery"
  "/logowanie" "/rejestracja" "/odzyskiwanie-hasla"}
 and not cf.client.bot)

Settings: count by IP, threshold 5 requests per 10 seconds, action Block for 10 seconds. A customer who opens the login page and submits the form makes 2 or 3 requests, so they will never notice. If your store uses a language prefix (/en/login), add the full paths to the list.

To be honest about limits: per-IP rate limiting slows single sources, but it will not stop a distributed attack from thousands of addresses. For that you need a captcha on login and a challenge rule in your spare slot. The Pro plan gives you 2 rate limiting rules, counting windows up to 1 minute and blocks up to 1 hour. If you are not on Cloudflare at all, mypresta.rocks has a guide to rate limiting PrestaShop without a WAF.

Captcha: where it helps and where it hurts

Captcha makes sense on login, registration, password recovery, contact and newsletter forms. Do not put a visible captcha on checkout: it is the most valuable page of your store, and every extra task is a reason to abandon the cart.

PrestaShop has modules for Cloudflare Turnstile, reCAPTCHA v3 and hCaptcha. Turnstile and reCAPTCHA v3 usually work without asking the human to do anything. Two practical notes:

• A captcha on login also blocks login checks in monitoring. In IThandy Monitor I handle this with an exception for the test account, or I skip the login check and keep the guest checkout test.
• After a theme change, check that the captcha script still loads. A form without its captcha script can reject every submission, customers included.

Cloudflare Bot Fight Mode: when it hurts a store

Bot Fight Mode on the Free plan is an on/off switch that no rule can bypass. Cloudflare's documentation says it plainly: "Currently, you cannot skip Bot Fight Mode, only Super Bot Fight Mode", and Super Bot Fight Mode is only on paid plans (Cloudflare skip options).

For a store, that means Bot Fight Mode can challenge traffic you consider useful: payment callbacks, inventory integrations, feed fetchers and monitoring. Your 00-allow Skip rule will not change that. You have two options:

1. Turn Bot Fight Mode off and rely on the custom rules and rate limiting described here. I did exactly this for a client who had all Free slots in use and needed integrations to work.
2. Move to Pro and use Super Bot Fight Mode, which a Skip rule can bypass.

What a block looks like in logs: a 403 with the cf-mitigated: challenge header, or a Cloudflare error page instead of your store's response.

How not to block customers, payments and monitoring

After every firewall change, check three things: can a customer get from the product page to payment selection, do payment callbacks still arrive, and does your monitoring get through without a challenge. A blocked payment callback means an order the customer paid for, sitting in PrestaShop without a payment status.

How I check:

• Cloudflare events. In Security, then Events, I filter by action (Block, Managed Challenge) and by /module/, cart and checkout paths. Any event on those paths needs a fix.
• Orders without status. If "awaiting payment" orders show up after a rule change although customers paid, start with the callbacks. More on this in payment method or shipping missing at checkout.
• Monitoring with an allow rule. IThandy-Checker identifies itself as Mozilla/5.0 (compatible; IThandy-Checker/1.0; +https://monitoring.ithandy.pl/checker) and sends an X-IThandy-Monitor header with a token unique to each store.

The User-Agent alone is not enough, because anyone can send it. A rule that lets through "everything from IThandy-Checker" would be a hole the first scanner finds. So the rule combines the User-Agent with the secret token:

(lower(http.user_agent) contains "ithandy-checker"
 and any(http.request.headers["x-ithandy-monitor"][*] eq "TOKEN_FROM_PANEL"))

Action Skip, first position. Skip the remaining custom rules, all rate limiting rules and managed rules, and in products, Browser Integrity Check and Security Level. The IThandy Monitor panel generates this rule with your store's token and can email it to whoever runs your Cloudflare. Step by step: how to allow IThandy-Checker.

If your own firewall still stops my bot, the panel shows "no monitoring access", not an outage. I never send an outage alert when the block comes from your own firewall.

Firewalls are also the reason to monitor more than the homepage. A cached homepage answers 200 OK even when a rule blocks the cart. PrestaShop checkout monitoring on the Shop plan opens a product page and adds it to the cart every 5 minutes; on Shop Pro it runs an order test every hour up to delivery and payment selection, without ever placing an order. See plans from 12 EUR a month and how it works.

Checklist: PrestaShop bot protection with Cloudflare

1. Ask your host which WAF rules run on their side (Imunify360, ModSecurity) and whether they block bots by User-Agent.
2. Check whether Bot Fight Mode is on. If it is, decide: turn it off, or move to Pro.
3. Create 00-allow (Skip, first): monitoring with token, payment module callback paths, integrations.
4. Create 10-admin with your admin folder name and an IP list or challenge.
5. Create 20-scanners: block /.env, /.git, /wp-login.php, /xmlrpc.php, /phpinfo.php, /install.
6. Create 30-auth-query: challenge controller=authentication, registration, password.
7. Add one rate limiting rule for login, registration and password recovery (5 requests per 10 s per IP, verified bots excluded).
8. Enable a captcha (Turnstile, reCAPTCHA v3 or hCaptcha) on login, registration, contact and newsletter. Not at checkout.
9. Turn off "Cache Everything" or add bypasses for the back office, cart, checkout and account.
10. Review Security, Events, then place a test purchase or run the order test in your monitoring.
11. Freeze firewall changes before Black Friday. The rest of the pre-peak list is in my Black Friday website monitoring checklist.

Want to know whether shoppers get through your firewall to payment before one of them complains in live chat? Start a 14-day free trial - it covers the Start plan, and I confirm the test scope for your store after the initial scan.

Sources

• Malwarebytes: Hi, robot: Half of all internet traffic now automated (Imperva Bad Bot Report 2025)
• Cloudflare: Skip options for custom rules
• Cloudflare: Rate limiting rules, plan availability
• Cloudflare: Custom rules
• mypresta.rocks: How to Set Up Cloudflare with PrestaShop Correctly
• mypresta.rocks: Rate Limiting and Bot Protection for PrestaShop Without a WAF
• Friends of Presta: security advisories