Cloudflare Application Profiles: как проверять профиль запросов
Cloudflare Application Profiles помогают находить запросы, отклоняющиеся от ожидаемой структуры приложения. Для владельца сайта это повод проверить штатные сценарии перед применением ограничений. Соответствие профилю не доказывает корректность бизнес-действия, а отклонение после обновления не следует автоматически считать атакой.
Две сентябрьские публикации и один механизм
Запись в changelog от 7 сентября 2026 года описывает Application Profiles как дополнительную модель позитивной безопасности. Блог от 29 сентября посвящён тому же направлению. Эти даты относятся к разным публикациям: поздний обзор не нужно выдавать за единственную дату появления механизма.
В первом доступном типе, Schema Profiles, ожидаемая структура включает поддерживаемые поля и их характеристики. Однако выбор защиты для приложения начинается с его рабочих операций. Перечень разрешённых процессов должен быть понятен владельцу продукта, иначе команда будет проверять только похожесть HTTP-запросов, а не сохранность работы сайта.
Наблюдение и блокировка разделены
Текущая документация разделяет построение профиля, классификацию запросов, анализ и применение Custom Rules. Профиль может опираться на наблюдаемый трафик или OpenAPI-схему. Само появление классификации не означает, что трафик уже блокируется.
Это позволяет сначала выяснить, какие нормальные действия попадают в отклонения. Для учебного примера возьмём сайт, где команда меняет оформление заказа и поиск. Таблица ниже — предлагаемая приёмка своего приложения, а не проведённое испытание Cloudflare или обещание конкретного результата детектора.
| Изменение учебного сайта | Штатное действие | Вопрос к проверке профиля | Кто объясняет норму | Какой результат нужен |
|---|---|---|---|---|
| В заказ добавлено поле | Клиент отправляет новую форму | Представлена ли новая структура в согласованном профиле | Разработчик оформления | Заказ проходит, отклонения объяснены |
| Изменён формат значения | Клиент выбирает разрешённый вариант | Совпадают ли ожидания профиля и контракт приложения | Владелец API и разработчик | Нет скрытого запрета допустимого варианта |
| Обновлён поиск | Посетитель вводит допустимый текст | Проверены ли реальные разрешённые форматы ввода | Команда продукта | Допустимый поиск сохраняется |
| Есть ещё старая версия клиента | Пользователь отправляет прежний поддерживаемый запрос | Учтено ли сосуществование версий | Ответственный за выпуск | Поддерживаемый клиент не теряет доступ |
Что должно попасть в набор штатных сценариев
Соберите разрешённые пути клиента, административной работы и интеграций в нужной области проверки. Не ограничивайтесь самым частым успешным запросом. Редкий, но нужный вариант может отсутствовать в коротком наблюдении, поэтому состав набора следует сверить с контрактом и командой продукта.
Не используйте чужие персональные данные ради теста. Рабочую форму можно проверить разрешёнными учебными значениями и сопоставить результат с ожидаемым действием. Секреты и содержимое пользовательских запросов не нужно переносить в общий отчёт о профиле.
Отдельно решите, как поступать при изменении сайта. Новая версия приложения и ожидания защиты должны быть согласованы. Не расширяйте правило вслепую только ради исчезновения предупреждения, но и не оставляйте остановленный процесс без ответственного за разбор.
Почему форма запроса не равна смыслу операции
Правильный тип поля ещё не говорит, имеет ли человек право изменить конкретный заказ. Мы советуем сохранять проверки доступа и бизнес-условий в приложении, рассматривая профиль как ещё один сигнал. Без этого удобная классификация может создать ложное ощущение завершённого аудита.
И обратное: необычная структура может появиться из-за разрешённого выпуска. Для решения полезны время изменения, версия клиента и результат штатного сценария. Одно слово «отклонение» не объясняет причину и не подменяет расследование.
Кому доступна функция
Документация указывает доступ через API Security и закрытое тестирование для приглашённых Enterprise-клиентов без него. Она отдельно предупреждает, что участие в beta не определяет будущие тарифы и доступность. Поэтому наличие подсказки «Cloudflare WAF free» не подтверждает бесплатность Application Profiles для любого сайта.
- Выберите ограниченную область приложения и перечислите разрешённые операции.
- Согласуйте источник ожидаемой структуры и представленные версии клиентов.
- Проверьте учебные штатные сценарии до изменения реакции защиты.
- Разберите отклонения с ответственными за приложение.
- Отдельно примите решение о нужных ограничениях и способе возврата.
- После выпуска сайта повторите существенные проверки и сохраните наблюдения.
Для защиты веб-приложения передайте не только название механизма, но и список рабочих процессов. При мониторинге безопасности определите ответственного за разбор, а в доработке сайта свяжите изменения формы с проверкой защиты. Новость полезна как повод наладить эту связь, без обещания полной защиты одним профилем.
Вопросы и ответы
Чем Application Profiles отличаются от Attack Score?
Профиль описывает ожидаемую структуру конкретного приложения и выявляет несоответствие ей. Документация рассматривает его как дополнение к другим сигналам, включая Attack Score, а не замену всей защиты.
Как разбирать отклонения Application Profiles?
Сопоставляйте результаты анализа со штатными сценариями и изменениями приложения. Перед ограничениями выясняйте, почему конкретный допустимый процесс отклонился от ожидания.
Application Profiles доступны бесплатно любому сайту?
Такого вывода из прочитанной документации нет. В ней указаны API Security и закрытая beta для приглашённых Enterprise-клиентов, без обещания будущей цены.
Читайте также
Обновили статью, пропали запросы: как проверить причину
SEOПо одному запросу кликают разные страницы: как проверить SEO-отчёт
SEOКак проверять SEO-отчёт: брендовые запросы и неполная выгрузка
КомментарииAstro 7.3: что проверить в собственном Cloudflare Worker
КомментарииВ YDB появился гибридный поиск: как проверить результат
SEOНастоящий ли Googlebot в логах: как проверить запросы