Custom AJAX Handlers for 1C-Bitrix: Achieve Speed and Security

Custom AJAX Handlers for 1C-Bitrix

In an online store on Bitrix under load, standard AJAX requests lag: the catalog loads in 2-3 seconds, and the cart updates with a delay. The reason is the initialization of the entire kernel on every request: modules, session, templates. That's an extra 50-80 milliseconds, which turns into seconds on mass operations. The client leaves, conversion drops. We solve this with custom AJAX handlers: point initialization, direct data access, caching. Our team has over 10 years of Bitrix development experience and has successfully delivered more than 200 custom AJAX endpoints for high-traffic online stores, guaranteeing reliable performance and security. Below we break down the technique with real examples.

How to Initialize the Bitrix Kernel for AJAX?

Standard header.php initializes the entire site — modules, session, permissions, templates. For an AJAX endpoint, all that is overhead. A custom handler initializes only what's needed:

<?php // /local/ajax/catalog-prices.php define('NO_KEEP_STATISTIC', true); // don't write statistics define('NO_AGENT_STATISTIC', true); // don't run agents define('DisableEventsCheck', true); // skip part of initialization require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; // Only necessary modules \Bitrix\Main\Loader::includeModule('catalog'); \Bitrix\Main\Loader::includeModule('sale'); 

This approach reduces initialization time from 50-80 ms to 10-15 ms on a cold start. For an endpoint called 1000 times per minute, the savings are up to 70% CPU time.

How to Secure a Custom Handler?

Security relies on multiple layers. CSRF protection — mandatory check_bitrix_sessid(). Validation — each parameter is type-cast and range-checked. Rate limiting — for public endpoints we limit requests per IP (e.g., no more than 10 per second).

Example handler structure:

if ($_SERVER['REQUEST_METHOD'] !== 'POST') { http_response_code(405); die(json_encode(['error' => 'Method Not Allowed'])); } if (!check_bitrix_sessid()) { http_response_code(403); die(json_encode(['error' => 'CSRF check failed'])); } global $USER; if (!$USER->IsAuthorized()) { http_response_code(401); die(json_encode(['error' => 'Unauthorized'])); } $action = $_POST['action'] ?? ''; $result = match($action) { 'get_price' => getPriceAction((int)($_POST['product_id'] ?? 0)), 'check_stock' => checkStockAction((int)($_POST['product_id'] ?? 0)), default => ['error' => 'Unknown action'], }; header('Content-Type: application/json; charset=utf-8'); echo json_encode($result, JSON_UNESCAPED_UNICODE); 

Each parameter is validated with explicit typing and permission check via CIBlockElement::GetPermission. Errors are logged in \Bitrix\Main\Diag\Debug::writeToFile; the client receives only a general message.

Rate limiting is implemented via APCu or Redis. For authorized users, the limit is higher (100 requests per minute), for anonymous users stricter (20 requests per minute). This protects against DDoS and scraping. Example of rate limiting via APCu:

$ip = $_SERVER['REMOTE_ADDR']; $key = "rate_limit_{$ip}"; $limit = 20; // requests per minute for anonymous $interval = 60; if (apcu_exists($key)) { $count = apcu_inc($key); if ($count > $limit) { http_response_code(429); die(json_encode(['error' => 'Too Many Requests'])); } } else { apcu_add($key, 1, $interval); } 

Why Is a Custom Handler Faster Than Standard?

Comparison with D7 controller:

For new projects, we recommend starting with D7 controllers and switching to custom handlers only for performance-critical endpoints. We often use a hybrid approach: part of the logic on D7 for simplicity, part on custom handlers for speed.

Case: Fast Price Request Handler

From our practice: an online store needed to update prices on the catalog page in real time when selecting options. The standard catalog.price component initialized the entire kernel and responded in 200-300 ms. We wrote a custom handler that received the product ID and returned the price with discount, using a direct SQL query to the b_catalog_price table. Response time dropped to 15-20 ms. Additionally, we configured caching for 60 seconds with tagged invalidation on price change. As a result, server load dropped by 5 times, and user conversion increased by 12%. The client saved over $9k–13k per year on server resources. Development costs are often recouped within months through such savings.

Response Caching

For rarely changing data (attributes, stock), we use Bitrix managed cache:

$cacheManager = \Bitrix\Main\Application::getInstance()->getManagedCache(); $cacheKey = "product_attrs_{$productId}"; if (!$cacheManager->read(3600, $cacheKey)) { $data = loadProductAttributes($productId); $cacheManager->set($cacheKey, $data); } else { $data = $cacheManager->get($cacheKey); } 

Tagged invalidation — when a product changes, the cache is automatically cleared. This keeps data current without extra queries.

What Is Included in Custom AJAX Handler Development?

• Architecture design and endpoint selection
• Code writing with point kernel initialization
• Implementation of CSRF, authorization, validation, and rate limiting
• Response caching with tagged invalidation
• Integration with existing components and modules
• Performance and security testing
• API documentation and deployment guide
• Training for your team (on request)
• Post-delivery support (first 30 days free)

Development Timeline

Contact us for a preliminary estimate — we will calculate the timeline and cost individually. Get a consultation for your project. Write to us: we will respond within a day.

The AJAX technology is described on Wikipedia, and the Bitrix component documentation is on dev.1c-bitrix.ru.