Почему капча не спасает от ботов — и как это исправить в России
Новости
Издание dev.to пишет, что стандартные reCAPTCHA не справляются с ботами-кард-тестерами на WooCommerce. Атаки обходят защиту, потому что боты не взаимодействуют с формой, а атакуют API напрямую. Это не просто технический сбой — это прямой урон бизнесу.
О чём речь и почему я считаю это важным для бизнеса
Речь о том, как боты с помощью автоматизированных запросов проверяют сотни тысяч украденных карт через checkout-формы. Это не теория — это реальные атаки, которые приводят к блокировке аккаунтов у платежных шлюзов, росту комиссий и падению доверия к мерчанту. Я считаю это важным, потому что сайт, который работает, не значит, что он защищён. А если защита устарела — бизнес теряет деньги, даже если ничего не делает.
Как это устроено — что тут вообще происходит
Боты не открывают браузер и не кликают по кнопкам. Они отправляют прямые HTTP-запросы на конечные точки WooCommerce: /?wc-ajax=checkout или /wp-json/wc/store/v1/checkout. Эти запросы не проходят через клиентскую часть, где работает reCAPTCHA. Поэтому капча, которая проверяет, что человек видит форму, не срабатывает. Боты просто игнорируют её. В итоге — тысячи запросов в минуту, и система принимает их как легитимные, пока не сработает защита на уровне платежного шлюза.
Что изменилось на рынке: как делали раньше и как делают сейчас
Раньше считали, что капча — универсальное решение. Добавил reCAPTCHA — и всё в порядке. Сейчас понимают, что это не так. Уязвимость не в форме, а в архитектуре: если защита только на клиенте, она не работает против headless-бота. Сейчас делают иначе — проверяют запросы на сервере, до того как они попадут в платёжный шлюз. Используют серверные ограничения по скорости, проверку токенов Turnstile и интеграцию на уровне ядра системы. Это не просто защита — это изменение подхода к безопасности.
Кому это касается и как понять, что это про ваш проект
Если у вас интернет-магазин на WooCommerce, и вы используете стандартные плагины капчи — это про вас. Особенно если у вас есть уведомления от Stripe о высоком риске, или вы замечаете аномальные пиковые нагрузки на checkout-страницы. Если вы не контролируете, кто и как отправляет данные на платёжный шлюз — значит, уязвимость есть. Даже если сайт «работает», он может быть неэффективным: каждый неудачный запрос — это комиссия, риск блокировки, потеря доверия.
Что с этим делать — порядок действий в общем виде
Сначала — аудит. Проверяем, как именно проходит checkout: через классический фронтенд или Store API. Затем — анализируем, где сейчас находится защита: только на клиенте, или есть серверные проверки. Если нет — начинаем с внедрения серверной защиты: лимиты по скорости, проверка токенов Turnstile на уровне хука. Важно, чтобы всё работало до вызова платежного шлюза. Потом — тестирование, мониторинг, адаптация. И не забывать, что безопасность — это не разовое действие, а постоянный процесс.
Что мы с этим делаем
В таких случаях мы в Cetera начинаем с аудита архитектуры checkout-процесса. Проверяем, какие точки доступа используются, как реализована защита, где возможны уязвимости. Далее — внедряем серверные механизмы: ограничение по скорости, интеграцию с Cloudflare Turnstile, проверку на уровне хука. Всё это делается без добавления тяжёлых библиотек, чтобы не замедлять работу сайта. Мы поддерживаем и развиваем проекты на Cetera CMS, 1С-Битрикс, Laravel, Yii2, InSales, WordPress, Magento2 и других платформах. Выбор платформы — это выбор скорости изменений на годы вперёд, а не разовое решение. Разбор того, что даст переход на другую платформу, поможет понять, как снизить риски и ускорить развитие.
Это часть нашей работы — Создание и разработка. Создание интернет-проекта — комлексная услуга, включающая весь производственный цикл: от сбора требований до запуска готового ресурса в интернете. Создание и разработка
Автор: Святослав Семенов из Cetera Labs
Новость для бизнеса в Нижнем Новгороде, Россия