Документация
Панель управления API

Схема работы Digital Fraud Protection

Пошагово описываем взаимодействие DFP с вашим сайтом / мобильным приложением и бэкендом.

Принцип работы, кратко

  1. Вы подключаете DFP: добавляете JavaScript-библиотеку DFP на нужные страницы сайта или встраиваете Servicepipe Mobile SDK в мобильное приложение.

  2. Пользователь открывает страницу сайта/приложения и выполняет на ней действие, для которого нужна проверка.

  3. Библиотека/SDK собирает параметры клиентского окружения.

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

  4. Библиотека/SDK отправляет собранные данные на API DFP.

  5. DFP анализирует особенности сетевого взаимодействия при выполнении браузером / мобильным приложением запроса — например, информацию из TLS-хендшейка и с L3/L4 сетевого уровня.

  6. DFP проводит итоговый анализ всех собранных данных. Затем упаковывает результат в JSON. Внутри указаны user_id, результат проверки на активность ботов, использует ли пользователь VPN или прокси, пришёл запрос из хостинговой подсети или обычной и другие параметры. Читать полный список параметров.

  7. DFP шифрует результат и возвращает его в браузер/приложение.

  8. Браузер/приложение передаёт зашифрованный ответ на ваш бэкенд.

  9. Ваш бэкенд расшифровывает ответ, проверяет результат и применяет вашу бизнес-логику.

Схема взаимодействия

  • DFP для сайта

  • DFP для мобильного приложения

Схема работы DFP для сайта
Схема работы DFP для мобильного приложения

Принцип работы, подробно

1. Вы подключаете DFP к своему сайту или мобильному приложению

  • Интеграция с сайтом: вы подключаете JavaScript-библиотеку DFP на страницах, где пользователь совершает защищаемые действия.

  • Интеграция с приложением: вы встраиваете Servicepipe Mobile SDK и вызываете его перед защищаемым действием.

Например, можно подключить DFP ко входу в аккаунт и проверять, со знакомого окружения или нет логинится пользователь.

2. Пользователь открывает страницу сайта или выполняет действие в приложении

На сайте браузер загружает JavaScript-библиотеку DFP при открытии страницы. В Android-приложении SDK уже инициализирован в классе Application.

3. Библиотека/SDK собирает данные клиентского окружения

Библиотека/SDK собирает параметры, которые помогают описать браузер и устройство пользователя.

Также вы можете передать свою строку данных через поле customData. Она не будет включена в отпечаток. Это просто данные, которые DFP примет и вернёт вам в неизменном виде. Через customData можно передать дополнительный контекст запроса, чтобы завязать на него вашу бизнес-логику — например, можно отправить тип события или идентификатор формы, которую заполняет пользователь.

Второй вид данных, которые вы можете отправлять, — customID. Как это поле обрабатывается и как влияет на результат DFP, настраивается индивидуально под вас. Логику нужно согласовать с нашими инженерами отдельно.

Рекомендация для интеграции DFP с сайтом: запускайте сбор данных о клиентском окружении как можно раньше (например, при открытии страницы), а их отправку в API DFP — в момент целевого действия (например, входа в аккаунт, отправки формы или подтверждения операции). Так вы будете получать ответ DFP быстрее и его точность будет выше. Как это настроить, читайте в инструкции по интеграции.

4. Библиотека/SDK отправляет данные на API DFP, происходит анализ сетевого взаимодействия

После сбора данных библиотека/SDK отправляет запрос на API DFP, в инфраструктуру Servicepipe.

На стороне Servicepipe запрос проксируется через ноды Web DDoS & Bot Protection, где установлено ПО, которое позволяет анализировать телеметрию запроса на L3-L7. Здесь собираются:

  • данные автоматизации,

  • информация из TLS-хендшейка,

  • информация L3/L4 сетевого уровня,

  • информация об особенностях передачи браузером информации на сервер.

Благодаря этому DFP получает более полную картину обращения, чем если бы анализировал только данные из браузера.

5. DFP формирует user_id

DFP создаёт отпечаток клиентского окружения и на его основе формирует user_id — стабильный идентификатор этого окружения.

Исключение: для запросов с white_bot: true DFP не вычисляет user_id и возвращает пустую строку ("user_id": ""). Подробнее о параметре white_bot.

Говоря проще, user_id — это ID, который описывает уникальную связку «конкретный браузер + конкретное устройство» (DFP для сайта) или уникальное устройство (DFP для мобильного приложения). Он остаётся стабильным, даже если пользователь поменяет какие-то настройки устройства/браузера/сети, например:

  • включит VPN,

  • обновит ОС,

  • поменяет время на компьютере/телефоне,

  • включит режим инкогнито в браузере,

  • обновит версию браузера.

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

Протестировать, как работает DFP, вы можете в нашем playground: открывайте эту страницу из разных источников, меняйте свои настройки — вы увидите, что User ID не поменяется, пока вы не смените браузер/устройство.

6. DFP формирует результат проверки остальных параметров

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

  • DFP для сайта

  • DFP для мобильного приложения

  • user_id — идентификатор клиентского окружения (ID связки устройство+браузер).

  • bot_score — пришёл запрос от бота или человека.

  • proxy_score — вероятность, что при отправке запроса использовался VPN или прокси.

  • proxy_signs — признаки, на основании которых DFP рассчитал proxy_score.

  • engine — какой браузерный движок используется: например, Blink, WebKit, Gecko или другой.

  • hosting — относится ли IP-адрес к хостинговой подсети.

  • bot_hosting — относится ли IP-адрес к хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность.

  • isp_active_subnet — относится ли IP к активной подсети интернет-провайдера, которая используется для подключения частных или корпоративных клиентов к интернету.

  • tor — относится ли IP к сети Tor, которая скрывает реальный адрес пользователя.

  • incognito — открыт ли браузер в режиме инкогнито или приватного просмотра.

  • antidetect — используется ли антидетект-браузер, который подменяет параметры браузера и отпечаток, чтобы с одного устройства можно было выдавать себя за разных пользователей.

  • vm — запущен ли браузер в виртуальной машине.

  • rdp — есть ли признаки использования программы для удалённого доступа.

  • webview — открыт ли ваш ресурс внутри другого приложения (WebView), например, по ссылке в мессенджере, а не в обычном браузере.

  • mobile — пришёл ли запрос с мобильного устройства.

  • os — какая операционная система используется: например, Windows, macOS, Linux, iOS или Android.

  • vpn — есть ли признаки использования VPN.

  • new_user — впервые ли ваш ресурс посещают из этого клиентского окружения.

  • confidence_score — степень уверенности в том, что user_id определён корректно.

  • white_bot — от доверенного ли источника пришёл запрос.

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

    Запросы с white_bot: true рекомендуем автоматически пропускать на вашем бэкенде. Для них DFP не вычисляет user_id и возвращает в этом поле пустую строку ("user_id": "").

  • user_id — идентификатор клиентского окружения (ID устройства).

  • bot_score — вероятность, что запрос отправил бот;

  • os — операционная система;

  • isp_active_subnet — относится ли IP к активной подсети интернет-провайдера, которая используется для подключения частных или корпоративных клиентов к интернету;

  • vpn — используется ли VPN;

  • hosting — из хостинговой подсети пришёл запрос или из обычной;

  • bot_hosting — пришёл ли запрос из хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность;

  • new_user — впервые ли ваш ресурс посещают из этого клиентского окружения;

  • confidence_score — степень уверенности в том, что user_id определён корректно.

Подробное описание полей читайте в статье Что значат поля из ответа DFP.

7. DFP шифрует результат

DFP шифрует payload и возвращает ответ. Помимо payload, в успешном ответе также есть служебные поля для расшифровки и диагностики:

  • cipher_type — алгоритм шифрования;

  • iv — вектор инициализации;

  • tag — тег аутентичности;

  • request_id — идентификатор запроса на случай, если нужно будет обратиться в поддержку.

Браузер / мобильное приложение получает ответ.

Сам клиент (браузер / мобильное приложение) не должен принимать решение по результату DFP, потому что клиент — недоверенная среда. Логика решения должна быть реализована на вашем бэкенде.

8. Браузер / мобильное приложение передаёт ответ на ваш бэкенд

Библиотека/SDK отправляет зашифрованный ответ DFP на ваш бэкенд.

9. Ваш бэкенд расшифровывает payload

Для расшифровки используется секретный ключ, который вы получили от Servicepipe.

После расшифровки бэкенд получает поля payload в открытом виде.

10. Ваш бэкенд проверяет timestamp

На вашем бэкенде должна быть настроена логика: не принимать ответы DFP старше нескольких секунд. Эта важная мера убережёт вас от replay-атак. Как это работает, читайте в статье Как использовать timestamp для защиты от replay-атак.

Если ответ DFP свежий, обработка продолжается.

11. Ваш бэкенд проверяет user_id и другие поля

Ваш бэкенд проверяет значения полей payload: user_id, bot_score, engine, os, mobile, incognito, isp_active_subnet, proxy_score, proxy_signs, tor, hosting, bot_hosting, antidetect, vm, vpn, rdp, webview, new_user, confidence_score, custom_data и white_bot.

Некоторые поля доступны только для интеграции DFP на сайт.

Также он сверяет новые значения со старыми. Например, в вашей базе данных могут храниться соответствия аккаунтов и связанных с ними user_id — это удобно использовать, например, чтобы оценить, из знакомого окружения логинится пользователь (риска нет) или нового (появился риск-фактор). В упрощённом виде это может выглядеть так:

user_id user_account last_seen

U_101

account_A

2026-05-28

U_102

account_A

2026-05-28

U_203

account_B

2026-05-27

12. Ваш бэкенд применяет бизнес-логику

Дальше решение зависит от настроенных вами правил. Например:

  • пользователь пришёл из знакомого окружения и bot_score низкий — пропустить действие без дополнительной проверки;

  • пользователь заходит в знакомый аккаунт из нового окружения — запросить дополнительное подтверждение;

  • новое окружение прошло проверку — связать новый user_id с пользователем;

  • один user_id связан с несколькими аккаунтами — использовать как сигнал мультиаккаунтинга;

  • у обращения высокий bot_score и запрос идёт из хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность, — ограничить действие или отправить на дополнительную проверку.

Мы подготовили несколько готовых сценариев настройки, которые можно реализовать на вашем бэкенде с помощью данных DFP:

13. Ваш бэкенд сохраняет результат для следующих обращений

После обработки ваш бэкенд сохраняет в базе данных user_id и значения других важных для ваших сценариев полей.

Это пригодится при следующих обращениях. Например, при новом запросе DFP снова вернёт user_id, а ваш бэкенд сможет проверить, встречался ли этот ID раньше, с каким пользователем был связан и какое действие нужно выполнить.