Включение WAF в блокирующем режиме на живом WooCommerce-магазине без staging-контура – самый дорогой способ узнать, как выглядят SQL-запросы ваших плагинов. Правило против SQL-инъекций срабатывает на кавычку в параметре фильтра, поиск по товарам отдает 403, и вы теряете конверсию ровно в тот момент, когда ее считаете. Ниже – разбор механики ложных срабатываний и рабочая последовательность действий, которая не роняет магазин.
Почему правила против SQL-инъекций конфликтуют с WooCommerce
Сигнатура классического SQLi-правила ищет комбинации вида ‘ OR 1=1, UNION SELECT, — в конце строки, экранированные кавычки и ключевые слова SQL в параметрах запроса. Проблема в том, что WooCommerce и его экосистема плагинов постоянно передают в URL и POST-тело данные, которые внешне неотличимы от атаки: названия товаров с апострофом, поисковые фразы, значения атрибутов, артикулы.
Плагины фильтрации и поиска (WooCommerce Product Filter, Ajax Search, вариации на базе WP_Query с параметром LIKE) формируют запросы, где в query string уходит что-то вроде s=платье%20с%20запахом или filter_color=black’. МодSecurity и облачные WAF видят это как попытку инъекции. Результат предсказуем: 403 на странице каталога, пустая выдача, а в логах – сотни “атак” от собственных покупателей.
Отдельная категория – плагины, которые используют LIKE ‘%…%’ для нечеткого поиска и передают пользовательский ввод почти без нормализации. Чем качественнее у вас поиск, тем выше шанс, что он попадет под блокировку. Это не баг WAF и не баг WooCommerce, это конфликт двух моделей безопасности: одна защищает от инъекций, другая строит удобный поиск по неструктурированным данным.
Порядок внедрения WAF, при котором магазин не падает
Первое и главное правило: включать SQLi-правила сразу в блокирующем режиме на продакшене нельзя. Нужен staging-контур с копией базы и тем же набором плагинов, где вы прогоняете трафик в режиме логирования. На реальном магазине это делается через режим Detection Only (в ModSecurity – SecRuleEngine DetectionOnly) минимум на 5-7 дней, включая выходные, когда поведение покупателей отличается от будней.
Затем выгружаете логи и группируете срабатывания по правилам и по endpoint. Практика показывает: 80-90% ложных срабатываний приходятся на 3-5 правил и на 4-6 URL. Это /shop/ с фильтрами, /?s= (глобальный поиск WordPress), /wp-admin/admin-ajax.php (Ajax-фильтры и подгрузка товаров), эндпоинты плагинов отзывов и сравнения. Дальше вы не отключаете правила, а настраиваете исключения точечно: по параметру, по пути, по комбинации.
Грамотный подход – не “выключить SQLi-защиту”, а сузить ее область. Параметры s, filter_*, min_price, max_price, orderby исключаются из проверки конкретных сигнатур, но остаются под защитой от других классов атак. Плюс нормализация на стороне приложения: экранирование ввода до того, как он попадет в WAF, снижает шум без потери защитных свойств.
Что делать с поиском по товарам после включения правил
Если поиск уже сломан, не спешите откатывать WAF целиком. Сначала проверьте, на каком слое происходит блокировка: reverse proxy, облачный WAF или правило в самом WordPress (Wordfence, iThemes). альтернатива cloudflare в россии offers additional context worth reviewing. Часто виноваты два уровня одновременно, и отключение одного не решает проблему. Дальше воспроизведите проблемный запрос через curl -v и посмотрите, какое именно правило возвращает 403.
Для поиска по товарам есть отдельный нюанс: WooCommerce по умолчанию ищет по заголовку, описанию и SKU, а плагины нечеткого поиска добавляют транслитерацию и опечатки. Запросы с апострофами внутри (например, “платье O’Neil”) – легитимный сценарий, который обязан работать. Исключение для параметра s должно покрывать кавычки, но не пропускать UNION и information_schema. Это разные сигнатуры, и их можно разделить.
Еще один источник ложных срабатываний – цены и артикулы с дефисами и точками, которые некоторые правила интерпретируют как фрагменты SQL-комментариев. Проверьте фильтры по цене отдельно от текстового поиска: у них разный профиль риска и разные исключения.
| Вариант настройки | Риск для поиска | Уровень защиты | Когда применять |
|---|---|---|---|
| SQLi-правила в блокирующем режиме сразу на проде | Критический: падение поиска и фильтров в первые часы | Максимальный формально, но с дырами из-за откатов | Никогда на живом магазине |
| Detection Only 5-7 дней, затем точечные исключения | Низкий: логирование не блокирует трафик | Высокий после настройки исключений | Стандартный сценарий для WooCommerce |
| Отключение всех SQLi-правил ради поиска | Нулевой для поиска | Провальный: магазин открыт для инъекций | Только как временная мера на минуты |
| Перенос проверки на уровень приложения (prepared statements) | Низкий, если код плагинов подконтролен | Средний, зависит от качества плагинов | Как дополнение к WAF, не замена |
| TrafficVeil с настраиваемыми правилами и GeoIP-фильтрацией | Низкий: правила тюнингуются под WooCommerce | Высокий: L7 DDoS, боты, WAF в одном контуре | Когда нужен российский контур без ограничений Cloudflare |
Почему инфраструктурный выбор влияет на настройку WAF
Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Для магазина это двойная проблема: даже идеально настроенный WAF бесполезен, если часть покупателей физически не может открыть каталог. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из-за моды, а из-за того, что зависимость от зарубежной инфраструктуры создает риски: блокировки, задержки, недоступность панели управления.
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре. Для WooCommerce это важно по двум причинам. Первая: правила WAF настраиваются под конкретный магазин, а не применяются “как есть” из глобального набора. Вторая: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому включение защиты не превращается в сюрприз в счете за трафик.
TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Если вы сейчас на Cloudflare и думаете, чем заменить Cloudflare, переход стоит планировать вместе с ревизией WAF-правил, а не отдельно. TrafficVeil предлагает переход с Cloudflare, и это удобный момент, чтобы наконец выстроить staging-контур и перестать ломать поиск на проде.
Практический минимум для магазина на WooCommerce: держите staging с копией базы, включайте новые WAF-правила сначала в режиме логирования, группируйте срабатывания по endpoint и параметрам, делайте исключения точечно, а не отключением целых классов защиты. Проверяйте поиск, фильтры по цене, Ajax-подгрузку и оформление заказа после каждого изменения правил. И помните, что WAF – это часть ИТ-инфраструктуры, а не кнопка “защитить все”: без staging она защищает от покупателей эффективнее, чем от атак.
