Веб-приложения и API — это полноценные точки входа в бизнес. Через них проходят транзакции, данные, сценарии пользователей и интеграции с партнерами. Чем больше сервисов, тем шире поверхность атаки. И тем выше шанс, что в потоках легитимного трафика окажется что-то лишнее.

В первой половине 2025 года российские компании зафиксировали более 63 000 атак. Это на 27 % больше, чем в прошлом году!

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

На внешнем рубеже работает WAF. Он фильтрует веб-трафик и отсекает известные угрозы. Но, у него есть слепая зона — внутренняя механика API, где решается, что именно сервису можно, а что нельзя. Здесь нужен API Firewall, который проверяет структуру запросов, ограничивает частоту обращений и анализирует поведение клиента. Вместе они формируют защиту, способную закрыть и технические, и логические векторы атак.

Как раз об этом и пойдёт речь в этой статье. Она для тех, кто хочет понять, зачем нужны WAF и API Firewall вместе.

Как работает WAF?

Web Application Firewall (WAF) — прикладной фильтр безопасности, который встаёт между интернетом и вашим приложением. Его задача заключается в том, чтобы не впустить в систему вредоносный трафик. WAF разбирает каждый HTTP-запрос на части, изучает заголовки, параметры, тело и контекст. В отличие от классического межсетевого экрана, он работает на уровне содержимого, а не только на уровне пакетов. 

Классический файрвол работает на сетевом и транспортном уровнях (L3–L4) и оперирует IP-адресами, портами и протоколами. Его задача заключается в изоляции сегментов сети и базовой фильтрации по источнику и назначению трафика. Например, в платформе BILLmanager реализован именно такой сетевой экран: правила позволяют блокировать соединения по протоколу, внешнему IP-адресу клиента или IP-адресу ресурса в виртуальном дата-центре. Речь идёт о сетевом файрволе, а не о WAF. Последний работает на уровне приложений (L7).

Чаще всего WAF разворачивают в режиме обратного прокси, когда все входящие запросы сначала проходят проверку и только потом попадают в приложение. Удобно для централизованного контроля, но есть минус — это задержки. В прозрачном прокси трафик идет через WAF без изменения адреса назначения, и для клиента с сервером соединение выглядит прямым. Полезно, когда нельзя менять сетевую схему. Режим моста предполагает включение WAF в разрыв сети на канальном уровне с анализом пакетов на лету при минимальных изменениях конфигураций, но с ограниченной масштабируемостью. Пассивная репликация трафика дает WAF копию потока для анализа без вмешательства в работу приложения. Подходит для мониторинга и отладки, но не для блокировки атак в реальном времени. Конкретный режим выбирают исходя из точки перехвата трафика, допустимых задержек, возможности менять инфраструктуру и того, требуется ли мгновенная блокировка или достаточно обнаружения угроз.

Методы анализа трафика в WAF разнообразны и часто работают в связке. Сигнатурный подход основан на поиске в запросах заранее известных шаблонов атак — от простых регулярных выражений до сложных последовательностей действий злоумышленника. Он срабатывает быстро, но требует постоянного обновления базы и легко обходится изменёнными запросами. Поведенческий анализ описывает нормальное взаимодействие клиента и сервера, фиксирует отклонения: аномальную частоту, нетипичные параметры, необычную последовательность шагов. Этот метод гибок, но сложен в настройке и требует глубокого понимания логики приложения. Сейчас в работу часто включают машинное обучение. Оно помогает снижать количество ложных срабатываний и выявлять новые векторы атак, которые не описаны в сигнатурах или правилах. Но эффективность моделей напрямую зависит от качества обучающих данных и архитектуры самого WAF, от того, как он собирает, нормализует и интерпретирует трафик.

На практике все перечисленные подходы комбинируют: сигнатуры отсекают очевидные угрозы, поведенческие правила ловят сложные сценарии, а ML-модели находят то, что ускользнуло от первых двух.

После анализа WAF принимает решение. Он может заблокировать запрос, изолировать источник по IP или другому признаку либо очистить вредоносные фрагменты и пропустить запрос дальше. В этом он похож на антивирус, только для веб-приложений. Также он интегрируется с SIEM, антифрод-сервисами и системами авторизации, становясь частью общей стратегии ИБ.

Надёжность WAF оценивают комплексным тестированием, максимально приближенным к реальным условиям эксплуатации и атакам. Сначала проводят функциональные проверки, чтобы убедиться, что фильтрация работает по заданным правилам, а легитимный трафик проходит без сбоев. Затем выполняют нагрузочные испытания, моделируя пиковые объёмы запросов для выявления пределов производительности и устойчивости к перегрузкам. Отдельно проверяют отказоустойчивость — реакцию системы на сбои в сети, перезапуски и переключение на резервные узлы. Для оценки уровня защиты используют сценарии, воспроизводящие распространённые типы атак на веб-приложения, включая попытки обхода фильтров. Проверяют и ложные срабатывания, особенно в сложных бизнес-процессах, где недопустима блокировка корректных запросов. В расширенных сценариях подключают команды, имитирующие действия злоумышленников, чтобы оценить, насколько реально обойти защиту.

Как работает API Firewall?

API напрямую связан с бизнес-логикой, обрабатывает данные и часто открыт во внешний мир. Любая ошибка в нём может стоить очень дорого.

По данным «Информзащиты», в 2024 году количество кибератак через уязвимости в API выросло на 630%. Около 60% корпоративных приложений содержат такие уязвимости. Эксперты отмечают, что в погоне за удобством и скоростью вывода функциональности бизнес часто пренебрегает безопасностью, что делает API приоритетной целью киберпреступников.

API Firewall берёт на себя задачу защиты этих интерфейсов. Он проверяет каждый входящий вызов, оценивает его структуру, частоту, контекст и соответствие политике безопасности.

В отличие от решений, которые ориентированы на общий веб-трафик, API Firewall работает с прикладными протоколами. REST, SOAP, GraphQL, gRPC, JSON-RPC — всё это в его зоне ответственности. Он анализирует не только заголовки, но и тело запроса, схему, типы данных, параметры и даже поведение клиента. Такой подход позволяет ловить атаки, которые проходят мимо классических фильтров. Среди них BOLA, mass assignment, schema poisoning.

В архитектуре API Firewall становится точкой контроля между клиентом и самим API. Он может работать в связке с IAM, WAF, SIEM, добавляя еще один уровень верификации и реагирования. Особенно полезен он в микросервисных системах, где API служит основным каналом общения между сервисами и внешними потребителями.

Тандем WAF и API Firewall

К примеру у вас есть интернет-магазин. Веб-сайт обслуживает клиентов через браузер, а мобильное приложение — через API. Для защиты фронтенда вы используете WAF, а для контроля доступа к API — специализированный брандмауэр.

Когда злоумышленник пытается внедрить SQL-инъекцию через форму на сайте, WAF, стоящий перед веб-сервером, распознаёт вредоносный паттерн и блокирует запрос до того, как он достигнет базы данных. Это классический сценарий, где WAF отрабатывает на уровне HTTP и защищает интерфейс от типичных атак.

Но, если атака идёт через мобильное приложение, картина меняется. Допустим, кто-то пытается получить доступ к платёжной информации, минуя авторизацию, напрямую через API. WAF может зафиксировать подозрительный трафик, но его возможностей недостаточно для глубокого анализа бизнес-логики запроса. Здесь вступает в работу API-брандмауэр: он проверяет, соответствует ли запрос политике безопасности, валидна ли конечная точка и есть ли у пользователя необходимые права. Если что-то не сходится — доступ блокируется и данные остаются в безопасности.

Так работает двухуровневая защита.

Веб-приложения и API различаются по архитектуре, но одинаково уязвимы. Их защита требует разных методов, но общей координации.

WAF анализирует HTTP-трафик, фильтрует запросы на уровне веб-интерфейса, блокирует SQL-инъекции, XSS и другие атаки из OWASP Top 10. Он эффективен для фронтенда и классических веб-приложений. API Firewall работает с REST, GraphQL, gRPC и другими прикладными протоколами. Он проверяет структуру вызова, сверяет схему, контролирует частоту, валидирует авторизацию и фильтрует инъекции, характерные для API-слоя. Его зона ответственности — OWASP API Security Top 10 и атаки, которые не видны на уровне HTML-форм.

Сейчас приложения все чаще используют WebSocket для двусторонней связи, gRPC для микросервисов и GraphQL для гибкой агрегации данных. Эти технологии ускоряют работу, но открывают новые векторы атак. Поэтому важно, чтобы WAF и API Firewall действовали согласованно.

Если убрать один из них, вторая зона останется открытой. WAF не остановит атаки на API, а API Firewall не защитит от XSS в браузере. В зрелых архитектурах оба решения работают в паре, как часть единой модели контроля доступа, фильтрации и мониторинга.

Как выбрать модель защиты?

Есть два варианта, расскажу о каждом подробнее.

Негативная модель

Основа классического WAF. Разрешено всё, кроме явно запрещённого. Система сверяет каждый запрос с базой известных угроз: SQL-инъекции, XSS, CSRF, DoS, bruteforce, поведенческие атаки. Обновил сигнатуры — и фильтр готов.

Плюсы: простота внедрения, широкий охват.

Минусы: высокая нагрузка, риск ложных срабатываний, постоянная зависимость от актуальности базы.

При поверхностной настройке — перерасход ресурсов.

Позитивная модель

Стандарт для API Firewall. Разрешено только то, что описано в профиле легитимного поведения. Любое отклонение блокируется.

Плюсы: точность, низкая нагрузка, быстрый отклик, гибкая настройка под конкретное приложение.

Минусы: зависимость от актуальности профиля и спецификации OpenAPI.

Нет OAS — нет фильтрации.

Если у вас фронтенд, который постоянно под прицелом самых разных атак, то логично опираться на WAF с негативной моделью. Если же в центре внимания API с критичной бизнес-логикой, то лучше работает API Firewall с позитивной моделью. А максимальный эффект даёт их совместная работа, когда оба подхода настроены под реальные потоки и угрозы, и действуют как единая система.

Метрики эффективности

Первое, на что стоит обратить внимание, так это на динамику инцидентов. Было десять успешных атак в месяц, а стало две — это уже результат.

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

Ложные срабатывания. Высокий процент блокировок легитимных запросов бьёт по бизнесу. Здесь помогает тонкая настройка и обмен данными между уровнями защиты. В результате должно стать меньше ошибок при сохранении чувствительности к атакам.

Есть и более тонкие показатели. Например, доля атак, остановленных WAF до того, как трафик дошёл до API Firewall. Или нагрузка на сам API Firewall после фильтрации. Эти цифры показывают, сбалансированы ли уровни защиты или один из них работает впустую.

В идеале всё это собирается в SIEM или SOC-дашборд. Там видно не только то, что происходит сейчас, но и то, как меняется картина с течением времени.

Защита должна быть многослойной

WAF и API Firewall работают в связке: первый отсекает угрозы на внешнем контуре, второй контролирует внутренние вызовы между сервисами. Вместе они формируют сплошной периметр, от браузера пользователя до глубины микросервисной архитектуры.

Конфигурация WAF и API Firewall учитывает топологию сервисов, маршруты трафика и форматы API. Это позволяет выстраивать непрерывный защитный контур и минимизировать риски обхода или ложных срабатываний.