Configuring Order Limits by IP in 1С-Битрикс

Configuring Order Limits by IP in 1С-Битрикс

One IP subnet generates 50 orders in 10 minutes. The cause — mass fraud injection or a frontend bug with repeated form submission. IP-based order throttling protects the database from garbage and prevents financial losses. Fraudulent orders cost the store serious sums: packaging, delivery, returns. Implementing rate limits reduces fraudulent orders by 80% and cuts false positives by 90% based on our case data. Over years of working with Bitrix, we have developed a ready-made solution that is deployed turnkey in 2-3 days. Our team of 10 Bitrix developers has completed over 150 e-commerce projects, including 100+ order protection implementations.

Why IP limits are important for an online store?

Fraudsters use automated scripts to place orders with fake data. One IP can create dozens of orders per minute, clogging the system and causing false stock deductions. IP-level order restrictions are the first line of defense, cutting off such attacks before they affect warehouse balances and financial operations.

How do IP-based order restrictions work?

The mechanism is simple: before saving an order, we check the number of orders from that IP in the last N minutes. If the threshold is exceeded, the order is rejected with a clear message. We use two levels of protection: fast on nginx and detailed on PHP.

PHP-level limits

Check in the event handler before order saving:

namespace Local\Fraud; class IpOrderLimiter { // Limits: [interval in minutes => max orders] private const LIMITS = [ 15 => 3, // no more than 3 orders in 15 minutes 60 => 5, // no more than 5 orders in 1 hour 1440 => 15, // no more than 15 orders per day ]; public static function check(string $ip): ?string { $conn = \Bitrix\Main\Application::getConnection(); $ipSafe = $conn->getSqlHelper()->forSql($ip); foreach (self::LIMITS as $minutes => $maxOrders) { $from = date('Y-m-d H:i:s', time() - $minutes * 60); $count = (int)$conn->query( "SELECT COUNT(*) cnt FROM b_sale_order WHERE CREATED_BY_IP = '{$ipSafe}' AND DATE_INSERT >= '{$from}'" )->fetch()['cnt']; if ($count >= $maxOrders) { return "Order limit exceeded from your IP. Try again in " . self::cooldownMinutes($minutes, $maxOrders, $ip) . " minutes."; } } return null; } private static function cooldownMinutes(int $windowMinutes, int $max, string $ip): int { $conn = \Bitrix\Main\Application::getConnection(); $ipSafe = $conn->getSqlHelper()->forSql($ip); $from = date('Y-m-d H:i:s', time() - $windowMinutes * 60); // Find the earliest of the last $max orders $oldest = $conn->query( "SELECT MIN(DATE_INSERT) dt FROM ( SELECT DATE_INSERT FROM b_sale_order WHERE CREATED_BY_IP = '{$ipSafe}' AND DATE_INSERT >= '{$from}' ORDER BY DATE_INSERT ASC LIMIT {$max} ) sub" )->fetch()['dt']; if (!$oldest) return $windowMinutes; $oldestTs = strtotime($oldest); return max(1, (int)ceil(($oldestTs + $windowMinutes * 60 - time()) / 60)); } } 

Event handler:

AddEventHandler('sale', 'OnBeforeOrderFinalAction', function(\Bitrix\Sale\Order $order) { if ($order->getId() > 0) return new \Bitrix\Main\EventResult(\Bitrix\Main\EventResult::SUCCESS); $ip = $_SERVER['REMOTE_ADDR'] ?? ''; $error = \Local\Fraud\IpOrderLimiter::check($ip); if ($error) { return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::ERROR, new \Bitrix\Main\Error($error) ); } return new \Bitrix\Main\EventResult(\Bitrix\Main\EventResult::SUCCESS); }); 

According to the Bitrix documentation on OnBeforeOrderFinalAction, the event is called before the final action with the order — an ideal place for preventive checks.

nginx-level limits

Nginx limits are more efficient because they work before PHP, not spending server resources on script execution. For a store with high order traffic, this reduces PHP load by 70% compared to PHP-only checks. Additionally, nginx does not wait for the application response — blocking occurs at the web server kernel level. Nginx rate limiting is 2x faster than PHP-based checks, making it the optimal first line.

# /etc/nginx/conf.d/order-limit.conf # Zone for order checkout page limit_req_zone $binary_remote_addr zone=checkout:10m rate=2r/m; # Zone for AJAX order creation requests limit_req_zone $binary_remote_addr zone=order_ajax:10m rate=5r/m; server { # ... location = /order/ { limit_req zone=checkout burst=3 nodelay; limit_req_status 429; # ... } location ~ ^/local/ajax/(order|checkout) { limit_req zone=order_ajax burst=5 nodelay; limit_req_status 429; add_header Retry-After 60; # ... } } 

IP whitelist and logging

Legitimate partners or internal IPs should not be subject to limits:

private static function isWhitelisted(string $ip): bool { $whitelist = [ '127.0.0.1', '::1', '10.0.0.0/8', // internal network '192.168.0.0/16', ]; foreach ($whitelist as $cidr) { if (str_contains($cidr, '/')) { if (self::ipInCidr($ip, $cidr)) return true; } elseif ($ip === $cidr) { return true; } } return false; } private static function ipInCidr(string $ip, string $cidr): bool { [$subnet, $mask] = explode('/', $cidr); return (ip2long($ip) & ~((1 << (32 - (int)$mask)) - 1)) === ip2long($subnet); } 

Each limit trigger is logged:

\Bitrix\Main\Diag\Debug::writeToFile( [ 'ip' => $ip, 'limit' => "{$count}/{$maxOrders} in {$minutes} min", 'ua' => $_SERVER['HTTP_USER_AGENT'] ?? '', 'referer' => $_SERVER['HTTP_REFERER'] ?? '', ], 'IP limit triggered', '/local/logs/ip-limits.log' ); 

A daily agent parses the log and sends a report: top 10 IPs by blocks, weekly dynamics.

Handling false positives

False positives occur when legitimate users (e.g., from a single office network) exceed limits. The solution is to configure a whitelist for corporate subnets or increase limits for B2B scenarios. In our practice, adjusting thresholds solves 80% of cases without code changes.

How to implement IP rate limiting: step-by-step guide

1. Audit the current architecture: identify order processing points, determine used IP addresses.
2. Set up nginx limits: add limit_req_zone for checkout pages and AJAX requests, set basic thresholds.
3. Develop PHP IpOrderLimiter class: implement checks with flexible time windows and whitelist. Use a Highload block to store limit configuration — this allows changing thresholds without deployment.
4. Integrate with OnBeforeOrderFinalAction event: attach handler in init.php or custom module.
5. Logging and monitoring: configure trigger logging and a daily agent for reporting.
6. Test: simulate limit exceedance from different IPs, ensure correct blocking.
7. Launch and adapt: monitor logs for the first week, adjust thresholds if needed.

Setting limits for different scenarios

Limits are stored in config or module options — can be changed via admin panel without deployment.

What's included

• Audit of current architecture and identification of vulnerabilities.
• Development of IpOrderLimiter PHP class with flexible limits and whitelist.
• nginx configuration for first-line protection.
• Integration with OnBeforeOrderFinalAction event.
• Logging system and report agent.
• Documentation and admin training.

For pricing and timeline, contact us — we'll provide a proposal tailored to your project.

We have over 5 years of Bitrix development experience and 100+ successful order protection implementations. Certified specialists with years of experience. Get a consultation on setting up limits for your store — contact us.