Rate limiting WooCommerce: как защитить Checkout и Store API от ботов

WooCommerce rate limiting — это встроенный механизм, который ограничивает слишком частые запросы к Store API. Для интернет-магазина он особенно важен на checkout: публичные endpoint-ы могут использовать не только покупатели, но и боты, скрипты перебора и card testing.

Store API предназначен для клиентской части магазина: каталог, корзина, доставка и оформление заказа. Он работает без обычных REST API-ключей, поэтому защита должна строиться не вокруг сокрытия endpoint-а, а вокруг ограничения частоты, правильной идентификации клиента, мониторинга и дополнительных антибот-мер.

Что именно защищает встроенный rate limiting

По официальной документации WooCommerce rate limiting для Store API является опциональным и по умолчанию отключён. Для общего режима базовые значения составляют 25 запросов за 10 секунд, а ограничения применяются к POST-запросам. Эти параметры можно менять фильтром woocommerce_store_api_rate_limit_options.

Отдельно WooCommerce позволяет включить более строгую защиту именно оформления заказа через WooCommerce → Settings → Advanced → Features → Rate limiting Checkout block and Store API. В этом режиме Place Order и POST /checkout получают лимит до трёх запросов за 60 секунд.

Почему checkout атакуют отдельно

Одна из типичных проблем — card testing. Автоматический скрипт отправляет серию попыток оплаты с разными карточными данными, используя реальный checkout магазина как способ проверки платёжных реквизитов. Это создаёт нагрузку, мусорные заказы, ошибки платёжного шлюза и риск блокировок со стороны платёжного провайдера.

WooCommerce отдельно описывает этот сценарий и рекомендует использовать встроенное ограничение checkout. Rate limiting не заменяет защиту платёжного шлюза, Turnstile или антифрод, но уменьшает скорость автоматической атаки и даёт сигнал для мониторинга.

Базовая настройка через фильтр

add_filter( 'woocommerce_store_api_rate_limit_options', function() {
    return [
        'enabled'       => true,
        'proxy_support' => true,
        'limit'         => 25,
        'seconds'       => 10,
    ];
} );

Не стоит без тестирования ставить экстремально маленький лимит. Checkout Block и сторонние расширения могут отправлять несколько последовательных запросов во время пересчёта адреса, доставки, купонов и оплаты. Слишком жёсткая настройка превращает защиту в источник ложных ошибок для реальных покупателей.

Cloudflare, reverse proxy и реальный IP

Если магазин работает за Cloudflare, балансировщиком или reverse proxy, особенно важен параметр proxy_support. Без корректной обработки forwarded headers несколько реальных покупателей могут выглядеть как один IP прокси. Тогда ограничение сработает не против бота, а против группы обычных пользователей.

Перед включением proxy support нужно убедиться, что инфраструктура действительно передаёт исходный адрес клиента через доверенные заголовки и что эти заголовки нельзя бесконтрольно подменить напрямую. Для сложной инфраструктуры лучше проверить цепочку CDN → nginx/Apache → PHP до изменения лимитов.

Кастомный fingerprint вместо одного IP

Начиная с современных версий WooCommerce Store API можно переопределить идентификатор rate limit через фильтр woocommerce_store_api_rate_limit_id. Это полезно, когда одного IP недостаточно: мобильные сети, корпоративные NAT и прокси объединяют многих людей за одним адресом.

add_filter( 'woocommerce_store_api_rate_limit_id', function() {
    $lang = isset( $_SERVER['HTTP_ACCEPT_LANGUAGE'] )
        ? sanitize_text_field( wp_unslash( $_SERVER['HTTP_ACCEPT_LANGUAGE'] ) )
        : '';

    return md5( wc_get_user_agent() . $lang );
} );

Такой fingerprint не является полноценной идентификацией пользователя и его нельзя считать средством аутентификации. Его задача — точнее группировать поток запросов для ограничения частоты.

Как диагностировать срабатывание ограничения

Store API возвращает служебные заголовки RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset и при превышении — RateLimit-Retry-After. Это позволяет отличить реальный rate limit от 403 Cloudflare, ошибки платёжного шлюза или обычного 5xx.

Для мониторинга можно использовать action woocommerce_store_api_rate_limit_exceeded и записывать безопасный технический контекст: время, endpoint, идентификатор ограничения, User-Agent и количество событий. Полные платёжные или персональные данные в лог писать не нужно.

Rate limiting на уровне WooCommerce и CDN — не одно и то же

Cloudflare WAF или nginx limit_req видят HTTP-трафик раньше WordPress и хорошо подходят для грубого отсечения аномального потока. WooCommerce rate limiting понимает контекст Store API и может точнее ограничить checkout. На практике эти уровни дополняют друг друга.

• CDN/WAF отсекает очевидный мусор до PHP.
• WooCommerce ограничивает Store API с учётом его логики.
• Платёжный провайдер применяет собственный anti-fraud.
• Turnstile или challenge можно включать для подозрительных сценариев.

Что проверить после включения

Не пытайтесь лечить rate limiting блокировкой всего Store API

Store API нужен современному WooCommerce для клиентских функций. Полное закрытие /wc/store/ через сервер или WAF может сломать Cart/Checkout Blocks и сторонние расширения. Лучше ограничивать опасные методы и маршруты, чем запрещать весь API.

Если checkout уже дорабатывался, полезно отдельно проверить совместимость с кастомизацией Checkout Block. А для нового магазина архитектуру защиты лучше заложить вместе с разработкой WooCommerce, а не добавлять после первой атаки.

Когда нужна кастомная настройка

Стандартный лимит подходит не всем магазинам. Высокий трафик, headless frontend, мобильное приложение, несколько CDN, внешние checkout-интеграции и нестандартные платёжные сценарии требуют отдельного анализа. Важно измерить нормальный профиль запросов и только затем выбирать лимиты.

A.S Groups может провести аудит WooCommerce checkout, Store API и серверной цепочки, настроить rate limiting, Cloudflare и логирование так, чтобы защита не блокировала реальных покупателей. Если магазин уже получает 429, странные платежные попытки или всплески нагрузки, можно начать с точечной диагностики WordPress и проверить проблему по логам.

Официальные источники

• WooCommerce: Rate Limiting for Store API endpoints
• WooCommerce: Card Testing Attacks and the Store API
• WooCommerce Store API documentation