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

Минимизируйте область действия исключения

  • Привязывайте правило к конкретному приложению и домену. Для этого используйте область проверки «Приложения» и по возможности «Хост» с оператором «Равно». 
  • Уточняйте путь и метод. Комбинируйте «Путь URL» или «URL» с оператором «Равно» либо «Начинается с», и добавляйте «HTTP‑метод» со значением GET/POST/.... Такой подход исключает лишние совпадения. 
  • Не расширяйте границы совпадения без необходимости. Операторы «Содержит» и «regex» применяйте только тогда, когда точное сравнение невозможно. Для чувствительных маршрутов используйте точные пути и параметры. 

Работайте адресно с параметрами и заголовками

  • Для GET/POST‑параметров и заголовков всегда указывайте имя поля в «sub_k» и подбирайте строгие операторы сопоставления. При необходимости используйте «Существует/Не существует» для валидации самого факта наличия поля.
  • Устанавливайте значения так, как они видны в журнале: с учётом кодирования (%2F, %20 и т. п.). Это исключит расхождения при проверке «Равно». 

Корректно комбинируйте условия

  • Помните о логике конструктора: внутри группы условия связаны "И", между группами действует "ИЛИ". Стройте правило так, чтобы каждая группа описывала один допустимый вариант запроса. 
  • Переключатель «Инвертировать результат (НЕ)» используйте только при явной необходимости инверсия усложняет проверку и повышает риск охватить лишний трафик. 

Избегайте чрезмерно общих исключений

  • Не применяйте шаблоны, охватывающие весь путь, домен или тело запроса. Предпочитайте «Равно» вместо «Содержит», «Начинается с» вместо широких регулярных выражений. Это критично для исключений, связанных с типовыми атаками в параметрах. 
  • Для сложных случаев разбивайте исключение на несколько независимых групп "ИЛИ" или на отдельные правила, чтобы упростить аудит и откат.

Проверяйте результат и пересматривайте исключение

  • После публикации проверяйте журнал событий: целевой запрос должен пройти без кода 403, а попытки эксплуатации уязвимостей по схожим маршрутам оставаться заблокированными. Используйте точные индикаторы из журнала для валидации. 
  • Устанавливайте регламент пересмотра исключений. Ложноположительные срабатывания обычно устраняются в приложении, после чего исключение следует сузить или удалить.

 

Короткие примеры в формате «Проблема → Решение»:

Проблема: блокируется единичный POST‑запрос по-точному URL из журнала инцидентов.
Решение: в конструкторе создайте правило с действием «Разрешить» и одной группой условий:

  • Приложения → Равно → нужный сайт
  • URL → Равно → значение из журнала (включая кодирование %)
  • HTTP‑метод → Равно → POST

Включите правило. Дополнительных операторов не требуется.

 

Проблема: CORS preflight (OPTIONS) ошибочно классифицируется как угроза.
Решение: одна группа условий:

  • HTTP‑метод → Равно → OPTIONS; Заголовок → «Origin» → оператор «Существует»
  •  Заголовок → «Access‑Control‑Request‑Method» → оператор «Существует»
  • Действие «Разрешить»

 

Проблема: веб‑хук от внешнего провайдера режется на уровне WAF, хотя источники IP доверенные.
Решение: одна группа условий:

  • Путь URL → Равно → /webhook/provider
  •  HTTP‑метод → Равно → POST
  • IP‑адрес источника → Равно → перечислите официальные IP провайдера
  • Действие «Разрешить»

 

Проблема: технический эндпойнт /admin/healthz нужен только из офисной сети, всё остальное должно блокироваться.
Решение: одна группа условий:

  •  Путь URL → Равно → /admin/healthz
  • HTTP‑метод → Равно → GET
  • IP‑адрес источника → оператор «В CIDR» → 10.10.0.0/16
  • Действие «Разрешить»

 

Проблема: один и тот же POST‑эндпойнт корректно принимает два допустимых Content‑Type. Первый проходит, второй блокируется.
Решение: используйте две группы условий, объединённых логикой ИЛИ:

  • первая группа: Приложения = сайт, Путь URL = /api/checkoutМетод = POST, Заголовок Content‑Type = application/json
  • вторая группа: те же признаки, но Content‑Type = application/vnd.api+json
  • Кнопка «Добавить группу (ИЛИ)» доступна в конструкторе

 

Проблема: ложное срабатывание на GET‑параметр limit, когда значение в допустимом диапазоне 1–100.
Решение: одна группа условий:

  • Путь URL → Равно → /api/search
  • Метод → Равно → GET
  • GET‑параметры → имя limit → оператор «Регулярное выражение» → шаблон, ограничивающий значения 1–100

 

Проблема: доступ к тестовому эндпойнту должен быть разрешён только из группы корпоративного VPN.
Решение: одна группа условий:

  • Путь URL → Равно → /internal/test
  • Метод → Равно → POST
  • IP‑адрес источника → оператор «В группе IP» → выберите нужную группу

 

Проблема: в исключении ошибочно охватывается слишком широкий диапазон, из‑за чего риск проницаемости повышен.
Решение: сузьте правило: предпочитайте операторы «Равно» и «Начинается с» для URL/Путь URL, исключите «Содержит» и избыточные регулярные выражения; не используйте инверсию «НЕ», если это не строго необходимо. 

Проблема: требуется временно разрешить конкретный запрос, сохранив возможность быстрого отката.
Решение: создайте отдельное правило с уникальным именем и описанием, установите действие «Разрешить», добавьте минимальный набор условий в одной группе, включите флаг «Включено». Для альтернативных вариантов запроса используйте дополнительные группы «ИЛИ», а не расширяйте одну группу. 

 

Внимание! Будьте предельно внимательны при создании правил исключения. ВСЕГДА проверяйте работоспособность, и анализируйте созданные исключения(е). Некорректно созданное(ные) правила могут существенно ослабить защиту приложения.

Данные примеры опираются на поддерживаемые области проверки и операторы конструктора правил, а также на механику групп «И»/«ИЛИ» и доступные методы HTTP для формирования правил исключений.