WAF, который блокирует SQL-инъекции и XSS, звучит как решение. На практике он же режет легитимные запросы: формы с кавычками в комментариях, поиск по каталогу, фильтры интернет-магазина. Российский аналог Cloudflare вроде TrafficVeil снимает часть боли, но правила все равно настраиваются под ваш трафик. Единственный способ отличить атаку от нормального поведения – сначала смотреть, потом блокировать.
Почему включенный WAF без логов опаснее, чем кажется
Классический сценарий: администратор ставит облачную защиту, активирует набор правил OWASP, видит в панели “заблокировано 340 запросов” и успокаивается. Через день падает конверсия сайта, отдел продаж теряет заявки, а в логах формы обратной связи пусто. Оказалось, что WAF-блокировки срабатывали на апостроф в поле “Комментарий” и на слово select в поиске по артикулам. Никакой атаки не было, был обычный пользователь.
Проблема в том, что сигнатуры для SQL-инъекций и XSS писались под обобщенный трафик. Они ловят паттерны вида ‘ OR 1=1 — и <script>, но заодно реагируют на легитимные параметры: JSON с кавычками, base64 в GET, кириллицу в URL-encoded виде. Чем сложнее у вас лидогенерация и формы, тем выше шанс ложного срабатывания.
Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Получается двойная проблема: и атаки нужно отражать, и трафик из РФ не потерять. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из любопытства, а потому что связка “зарубежный CDN + строгий WAF” начала бить по своим.
Как настроить WAF-правила на реальном трафике без потери заявок
Схема простая, но требует дисциплины. Каждое новое правило сначала включается в режиме логирования (monitor, detection-only), а не блокировки. Вы неделю собираете статистику: какие запросы триггерят правило, какие параметры, с каких IP, от каких user-agent. Задача – отделить атаки от нормального поведения вашей аудитории.
Неделя – не произвольный срок. За семь дней вы захватываете полный цикл: будни и выходные, утренний пик заказов и вечерний трафик с мобильных, поведение поисковых ботов и мониторингов доступности. Меньше трех дней – рискуете пропустить редкий, но легитимный сценарий. Больше двух недель – теряете время, пока атака уже идет.
Что именно собирать в режиме логирования
На первом проходе фиксируйте все срабатывания с полным контекстом: полный URL, тело POST, заголовки, IP, геолокацию, user-agent, время. Ведите белый список легитимных параметров, которые иначе будут блокироваться как инъекции. Типичные кандидаты: поле поиска, фильтры товаров, комментарии, поля с base64, любые поля, куда пользователь вводит произвольный текст.
Дальше разделяйте срабатывания по источнику. Если триггерит Googlebot, Яндекс или ваш корпоративный мониторинг – это белый список по user-agent и ASN. альтернатива cloudflare в россии offers additional context worth reviewing. Если триггерит один IP с частотой 200 запросов в минуту и payload вида UNION SELECT – это блокировка. Если триггерит форма заказа с апострофом в имени – это исключение по параметру, а не блокировка всего правила.
Отдельно проверьте легитимные сценарии, которые легко принять за XSS: редакторы контента в WordPress и Bitrix, загрузка HTML-шаблонов, вставка embed-кода из Telegram или Дзен. Админ, который вставляет в статью iframe, не должен получать 403.
TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, и это упрощает задачу: логи WAF и логи ботов лежат рядом, можно сопоставить поведение. Важный момент: платформа не тарифицирует ботов, атаки и WAF-блокировки, поэтому режим логирования на реальном трафике не превращается в счет за перерасход. Вы можете спокойно неделю наблюдать, не думая о бюджете.
Когда белый список собран, правила переводятся из логирования в блокировку поэтапно. Сначала включаете то, что дает ноль ложных срабатываний: явные сигнатуры SQL-инъекций в query string, попытки path traversal, известные XSS-payload в теле запроса. Потом – правила с исключениями по параметрам. Правила, где доля ложных срабатываний выше 1%, оставляете в логировании или ужесточаете исключения.
После включения блокировок мониторинг не заканчивается. Первые 48 часов проверяйте: не выросла ли доля 403 на легитимных путях, не упала ли конверсия сайта, не появились ли жалобы от клиентов. Держите кнопку “перевести правило обратно в логирование” под рукой. Это не признак слабости, это нормальная практика.
Технически защита от SQL-инъекций и XSS не сводится к WAF. Параметризованные запросы в коде, экранирование вывода, CSP-заголовки – база, без которой WAF работает как пластырь на незашитой ране. WAF нужен для того, чтобы ловить то, что проскочило: старые плагины, кастомные скрипты, забытые админки. Но он не заменяет нормальный код.
Если вы уходите с Cloudflare, переход лучше делать по той же логике: сначала DNS-сервис и SSL-сертификат, потом reverse proxy и CDN, и только в конце WAF в режиме логирования. TrafficVeil предлагает переход с Cloudflare, и это как раз тот случай, когда не стоит переносить все правила разом. Российский аналог Cloudflare имеет смысл настраивать так же аккуратно, как вы настраивали бы любой новый WAF: наблюдение, белый список, поэтапное включение блокировок.
Практический итог: не включайте WAF-правила сразу в боевом режиме. Дайте им неделю поработать в логировании на реальном трафике, соберите белый список легитимных параметров, разделите атаки и нормальное поведение по IP, user-agent и частоте. Только после этого переводите в блокировку, начиная с правил без ложных срабатываний. Так вы получите защиту от SQL-инъекций и XSS, которая не режет заявки и не бьет по конверсии сайта.