A malicious bot often does not look like a database attack. It is clean hits on login, the cart or the product list, repeated from many addresses. In the store log you see a jump in errors. On the server you see busy PHP processes.
Cloudflare sits in front of the store: domain DNS points at the edge, encryption ends there, and the store server does not have to be public. Bot score, a JavaScript challenge and a request limit cut traffic before it reaches PHP and the database.
Why a store needs this
You use it when the store or API gets a mass of requests that do not buy: password stuffing, catalogue scraping, card testing. Verified bots, search and monitoring, stay allowed. The rest with a low score get a challenge or a block.
You set a request limit on login, search and the cart. The payment webhook must be an exception. Otherwise the order is lost.
How to set it up
In Cloudflare on the store domain: full encryption to origin, an origin certificate, security level medium. Under Bots you enable Bot Fight. On Pro and above, Super Bot Fight: definite automation blocked, likely automation challenged, verified bots allowed.
In WAF you add a rule on login paths with a low bot score. A separate limit: a dozen requests per minute per IP on login. An exception for the Stripe, PayU or Przelewy24 path.
If the challenge catches real customers behind a corporate proxy, you narrow the rule to the path, not the whole hostname. On the store server you open 443 only from Cloudflare addresses.
Layer description: security.
In short: the edge takes off the server the traffic that does not buy. A rule without a payment exception breaks checkout. The Cloudflare log shows whether you are cutting bots or customers.