Bots Overload OT Commerce Store on OT Box, Spike Paid OTAPI Calls Mistaken for DDoS Attack

An online store running OT Commerce experienced CPU loads reaching 98-100% and a 6-7x increase in paid OTAPI calls over three days due to automated bot traffic rather than a traditional DDoS. The site owner had already deployed a paid anti-bot module on the VPS, yet behavioral bots continued to bypass protections and force expensive calls to the external OTAPI platform for product data from Taobao, Tmall, 1688 and other marketplaces. Traffic analysis after switching to the CRONARMOR WAF revealed that 41.9% of page requests were automated, with 99.3% of early-stage automation blocked before reaching the origin server. Only 0.5% were behavioral bots visible in analytics, while legitimate search crawlers accounted for 27,190 requests that were explicitly allowed. The WAF approach stopped requests at the reverse proxy layer, preventing PHP execution, database queries and OTAPI billing events on the origin. Post-deployment CPU dropped to single digits for most of the day, eliminating both performance issues and the anomalous rise in paid API usage.

HabrTranslated from Russian

Read at source

An online store built on OT Commerce faced severe performance degradation and sharply rising operational costs when automated bots began systematically crawling product pages. CPU utilization repeatedly hit 98–100% while the number of paid calls to the external OTAPI platform increased six- to seven-fold over three days.

The owner initially described the problem as a DDoS attack because requests arrived from many different IP addresses across multiple countries. However, the traffic was not a volumetric network-layer assault but rather automated HTTP requests that triggered heavy server-side logic and billable OTAPI operations.

The store uses the ready-made OT Box solution, which integrates with the OpenTrade Commerce platform via OTAPI. When a visitor opens a category, search result or product card, the engine may call paid methods such as SearchItemsFrame, GetItemInfo or GetItemFullInfo to fetch live data from Taobao, Tmall, 1688, Alibaba and other marketplaces. Each such call is metered, and some operations carry a multiplier cost.

A previously installed anti-bot module running directly on the VPS failed to stop the problematic traffic. The module’s vendor confirmed it was not designed to address large-scale parsing scenarios. After the owner restricted access to product cards for unauthenticated users, the automated activity persisted.

Switching the site behind the CRONARMOR WAF reversed the situation. Within hours of the cut-over on 16 September, CPU load fell from peaks of 80–100% to mostly single-digit percentages. Over the following 24 hours the server rarely exceeded 9% utilization.

Filtering statistics for the partial period showed 279,680 total HTTP requests, of which 276,100 targeted web pages. Automated requests blocked at the earliest stage numbered 115,660 (41.9%), with 99.3% of them never reaching the origin. Behavioral bots visible in analytics accounted for only 1,367 requests (0.5%), while 27,190 legitimate search-engine crawlers were explicitly permitted.

The case illustrates that high CPU combined with rising external API costs can result from scraping bots rather than classic L7 DDoS. Proper distinction requires analysis of request patterns, not merely the number of source countries or visible analytics events.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users
Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts
Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria