Что такое WAF и зачем он нужен сайту, о котором заботятся

Сеть и файрвол · 23.09.2026 · обновлено 13.10.2026 · 9 мин чтения · Команда НПП РЕКОРД

Файрвол на периметре и антивирус на сервере не видят, что происходит внутри HTTP-запроса к вашему сайту. Именно там живут SQL-инъекции, подбор паролей и эксплуатация свежих уязвимостей CMS. Разбираем обстоятельно, что такое WAF, чем он отличается от обычного файрвола и когда без него не обойтись.

Коротко. WAF (межсетевой экран веб-приложений) — фильтр между посетителем и сайтом, который разбирает содержимое каждого HTTP-запроса и блокирует атаки: SQL-инъекции, XSS, подбор паролей, сканирование уязвимостей и DDoS на уровне приложения. Обычный файрвол и антивирус этих атак не видят. Главная польза WAF — «виртуальный патч»: он закрывает известную уязвимость CMS за часы, пока разработчики готовят обновление. Подключают его поэтапно, через тестовый режим, чтобы не заблокировать живых клиентов.

Сайт или личный кабинет клиентов — это витрина бизнеса, обращённая в открытый интернет. Обычный файрвол хорошо фильтрует IP-адреса и порты, но он не читает содержимое HTTP-запроса. Он честно пропустит на сайт и обычного покупателя, и злоумышленника, который в поле «Имя» вписал не имя, а кусок SQL-кода. Разбираемся, что закрывает эту брешь и как это работает на практике.

WAF стоит перед веб-приложением и разбирает содержимое каждого запроса — а не только его адрес и порт

Что такое WAF простыми словами

WAF (Web Application Firewall, межсетевой экран веб-приложений) — это фильтр, который стоит между посетителем сайта и самим приложением. Он разбирает каждый HTTP-запрос по содержимому: что именно передано в форме, в заголовках, в параметрах адресной строки, — и сравнивает с образцами известных атак. Подозрительный запрос блокируется или помечается ещё до того, как он долетит до кода сайта и базы данных.

• SQL-инъекции — попытка вписать в поле формы фрагмент SQL-запроса, чтобы вытащить или испортить данные в базе.
• XSS (межсайтовый скриптинг) — внедрение вредоносного кода на страницу, который потом выполнится в браузере других посетителей.
• Брутфорс формы входа — автоматический перебор паролей ботом, который стучится в форму авторизации тысячи раз в минуту.
• Сканирование уязвимостей — боты методично проверяют известные адреса админок, старые версии плагинов и типовые дыры CMS.
• DDoS на уровне приложения (L7) — не забивание канала трафиком, а множество «дорогих» запросов, которые кладут сервер изнутри.

Чем WAF отличается от обычного файрвола и антивируса

Три слова звучат похоже, но защищают совсем разное. Путаница здесь — частая причина, почему сайт остаётся открытым, хотя на бумаге «защита есть».

Совет. Эти три инструмента не конкурируют, а дополняют друг друга: файрвол закрывает периметр по портам, антивирус — сервер от вредоносных файлов, WAF — само веб-приложение от атак через логику запросов. Уберите любой из трёх — и в защите останется зона, которую не видят два других.

Что бывает без WAF

Уязвимость в коде сайта или в стороннем компоненте CMS есть почти всегда — это данность любой достаточно живой системы. Вопрос не «есть или нет», а «эксплуатируема ли она прямо сейчас». Без WAF ответ обычно «да»: боты сканируют популярные CMS на известные уязвимости круглосуточно, и как только эксплойт для новой дыры появляется в открытом доступе, атаки на неисправленные сайты начинаются в течение часов, а не недель.

Важно. Разработчик CMS выпускает патч на известную уязвимость в среднем через одну-две недели после публикации, а иногда и позже. Всё это время сайт с непропатченной версией — открытая цель для любого, кто читает те же открытые базы уязвимостей, что и специалисты по ИБ.

Между публикацией уязвимости и выходом официального патча — окно в дни и недели, когда сайт беззащитен без WAF

Виртуальный патч: как WAF закрывает дыру за часы, а не за недели

Здесь и работает то, что называют «виртуальным патчем». Пока разработчики CMS или плагина готовят официальное обновление, WAF получает правило, которое блокирует именно способ эксплуатации конкретной уязвимости на уровне запроса — до кода дело просто не доходит. Сайт продолжает работать на старой версии, но конкретная дыра закрыта снаружи. Когда выходит официальный патч, его ставят в плановом порядке, без паники и ночных работ.

Как WAF подключают, не сломав сайт для живых клиентов

Главный страх при внедрении WAF — заблокировать не хакера, а обычного покупателя с необычным именем или сложной формой заказа. Правильное внедрение всегда идёт по шагам, а не «включили и забыли»:

1. Аудит веб-приложения — определяем точки входа: формы, API, админку, личный кабинет, — которые нужно закрыть в первую очередь.
2. Подбор и настройка правил под конкретный сайт и CMS, а не типовой набор «из коробки».
3. Тестовый режим — WAF какое-то время только наблюдает и логирует, не блокируя ничего, чтобы найти ложные срабатывания на реальном трафике.
4. Включение блокировки — переводим в активный режим только после того, как правила проверены и не задевают настоящих посетителей.
5. Мониторинг и донастройка — атаки меняются, правила обновляют, а не ставят один раз на годы вперёд.

Тестовый режим перед включением блокировки — это то, что отличает аккуратное внедрение WAF от «сломали сайт в первый день»

Ложные срабатывания — главный операционный риск

Слишком строгие правила блокируют реальных клиентов: адрес с апострофом, длинное сообщение в форме обратной связи, специфичный формат номера заказа. Слишком мягкие — пропускают атаки. Баланс между ними — не разовая настройка, а постоянная работа: нужно регулярно смотреть отчёт по заблокированным запросам и отличать реальную атаку от несчастного покупателя.

Совет. Хороший признак работающего WAF — не «ноль заблокированных запросов», а внятный отчёт: сколько атак отражено, какого типа, с каких адресов. Если отчёта нет и посмотреть не на что — скорее всего, WAF настроен для галочки, а не для защиты.

Кому WAF нужен в первую очередь

• Интернет-магазины и любые сайты с оплатой — атака на форму оплаты бьёт напрямую по деньгам и репутации.
• Личные кабинеты клиентов — там персональные данные, а значит, и требования регуляторов, и цена утечки выше.
• Сайты на популярных CMS (WordPress, Bitrix и аналогах) — именно под них боты держат готовые базы эксплойтов.
• Любая форма входа или регистрации, доступная из интернета, — она первая цель для перебора паролей.
• API, который отдаёт данные мобильному приложению или партнёрам, — его тоже сканируют, просто реже об этом вспоминают.

Итог

WAF не заменяет ни обычный файрвол, ни грамотно написанный код, ни регулярные обновления CMS. Но он закрывает конкретную и постоянно эксплуатируемую брешь: окно между появлением уязвимости и её официальным исправлением, а заодно — постоянный фон из ботов, которые ищут слабые формы и админки. Для сайта, через который идут деньги или данные клиентов, это не опция «на будущее», а базовая гигиена, наравне с резервными копиями и антивирусом.

Файрвол защищает периметр, антивирус — сервер, а WAF — само приложение, куда обращаются реальные посетители. Уязвимость в коде почти неизбежна. Открытое окно для её эксплуатации — нет.

Теги: WAF, веб-приложения, SQL-инъекции, OWASP, виртуальный патч