Что происходит с вашим номером после нажатия «Отправить»: разбираю путь одной заявки
Форма на сайте выглядит безобидно: имя, телефон и одна кнопка. Но владелец бизнеса часто не может сразу ответить, что происходит дальше.
Заявка уходит на почту? В CRM? Сначала в сервис автоматизации? Получает ли её система аналитики? Остался ли в коде старый обработчик после смены подрядчика?
Я разрабатываю «Периметр», инструмент для технической проверки публичной части сайтов. Одна из его задач состоит в том, чтобы показать наблюдаемый маршрут формы, не создавая настоящую заявку.
Для этого разбора я использовал безопасный контрольный сценарий. Реальный номер телефона не вводился, лид в CRM не создавался, чужой сайт без разрешения владельца не тестировался.
Что именно скрывается за кнопкой
В простом варианте форма отправляется на тот же сервер, где работает сайт. В более сложном сценарии между посетителем и отделом продаж появляется несколько звеньев.
↓text Страница сайта↓
↓ JavaScript-обработчик формы↓
↓ POST-запрос на endpoint↓
↓ CRM, почта или сервис интеграции↓
Сотрудник компании
Шаг 1. Сначала нужно понять, что собирает форма
До разговора о передаче данных стоит составить простой перечень полей. На контрольной форме это были имя, телефон и чекбокс рядом со ссылкой на документ.
На реальном сайте всё бывает сложнее. Кроме видимых полей, форма может содержать рекламную метку, идентификатор страницы, название услуги или скрытый технический параметр.
«Периметр» фиксирует названия и типы полей, обязательность заполнения, исходное состояние чекбокса и ссылки внутри формы. В отчёт не нужно переносить введённые значения посетителя.
Уже на этом этапе появляются полезные вопросы:
- зачем форме нужны именно эти сведения;
- соответствует ли перечень полей заявленной цели;
- открывается ли политика или согласие по ссылке;
- не выбран ли чекбокс заранее;
- одинаково ли оформлены формы на разных страницах.
Наличие галочки не даёт автоматического ответа о законности обработки. Согласие является не единственным возможным основанием. Но интерфейс можно проверить как факт: есть ли элемент, в каком он состоянии и какой документ видит пользователь.
Шаг 2. Вместо настоящего номера используется синтетический
Следующая задача сложнее. Статический HTML не всегда показывает реальный адрес отправки. Современная форма может собираться JavaScript, а запрос появляется только после нажатия кнопки.
Поэтому браузерный режим заполняет разрешённые поля уникальными тестовыми значениями. Для телефона создаётся синтетический номер, для почты используется домен `example.invalid`, а текстовое поле получает одноразовый маркер.
Эти значения нужны только для того, чтобы связать действие с подготовленным запросом. Они не сохраняются в клиентском отчёте.
Шаг 3. Браузер готовит запрос, но сервер его не получает
После заполнения контрольной формы браузер нажимает кнопку и наблюдает за сетевыми событиями. Если появляется изменяющий запрос, например `POST`, `PUT`, `PATCH` или `DELETE`, он перехватывается и отменяется.
В результат попадают только безопасные метаданные:
- страница, на которой найдена форма;
- имена проверенных полей;
- метод запроса;
- адрес endpoint без параметров, фрагментов и учётных данных;
- отметка о том, что запрос был подготовлен и отменён.
Тело запроса, заголовки авторизации и синтетические значения в отчёте не сохраняются.
Это позволяет ответить на узкий, но практический вопрос: куда форма попыталась обратиться после нажатия кнопки? При этом заявка не должна попасть на сервер и превратиться в тестовый лид для отдела продаж.
Такой результат всё равно нельзя пересказывать как «номер точно хранится на этом сервере». Корректная формулировка другая: «после заполнения формы браузер подготовил запрос к этому endpoint, запрос был отменён до отправки».
Шаг 4. Внешние сервисы нужно отделять от получателей формы
Во время загрузки страницы браузер может обратиться к аналитике, карте, чату, CAPTCHA, рекламному пикселю, CDN или внешнему шрифту. Список таких подключений полезен, но его легко интерпретировать неправильно.
Соединение с внешним доменом не доказывает, что ему передали телефон из формы. Для такого вывода нужно исследовать состав конкретного запроса, настройки сервиса и контекст обработки.
Поэтому в отчёте должны быть разделены две сущности:
1. Endpoint, который появился после действия с формой.
2. Сторонние домены, загружавшиеся на странице.
Если смешать их в один список «кому передаются персональные данные», получится громкое, но недоказанное обвинение.
Где здесь начинается 152-ФЗ
Согласно [статье 3 Федерального закона № 152-ФЗ], обработка включает не только хранение, но также сбор, запись, использование, предоставление и передачу персональных данных.
Технический маршрут формы поэтому имеет значение. Владелец сайта должен понимать, какие системы участвуют в процессе и совпадает ли фактическая конфигурация с документами и договорённостями.
Но один сетевой запрос не даёт полной правовой картины. Публичный скан не знает:
- на каком основании организована обработка;
- что написано в договорах с подрядчиками;
- где фактически размещена основная база данных;
- сколько хранится заявка;
- кто из сотрудников имеет доступ;
- куда первый получатель передаёт данные дальше.
Поэтому «Периметр» не выносит автоматический вердикт о соответствии закону. Он собирает технические факты для ручной проверки владельцем, разработчиком и при необходимости юристом.
Что владелец сайта может проверить уже сегодня
Для первой инвентаризации не нужен специальный сканер. Откройте сайт и задайте разработчику пять вопросов:
1. Какие формы сейчас работают на сайте, включая всплывающие и мобильные? 2. Куда отправляется каждая форма? 3. Какие CRM, чаты, системы аналитики и интеграции подключены? 4. Какие из них появились уже после подготовки политики? 5. Кто проверял этот список после последнего обновления сайта?
Если ответы приходится собирать у трёх подрядчиков, проблема уже обнаружена. Она пока не доказывает нарушение, но показывает отсутствие единой карты обработки.
Ещё один простой тест: сравните форму с опубликованными документами. Указаны ли правильный оператор, цель, категории данных и способ связи для отзыва? Открываются ли ссылки? Не осталось ли на сайте старой формы, о которой никто не помнит?
Зачем я делаю «Периметр»
Моя гипотеза состоит в том, что владельцу сайта нужен не ещё один универсальный чек-лист и не пугающая сумма возможного штрафа. Нужен проверяемый отчёт, в котором разделены:
- наблюдаемый факт;
- место его обнаружения;
- техническое доказательство;
- уровень уверенности;
- область, которую проверить не удалось;
- рекомендация для разработчика;
- вопрос, требующий юридической оценки.
Ответьте в комментариях: вы знаете, куда уходит заявка с вашего сайта после нажатия «Отправить»? Какое доказательство вы хотели бы увидеть в техническом отчёте, чтобы ему доверять?
Если хотите проверить собственный сайт, можно прислать домен в личные сообщения. Публичную часть я могу посмотреть без активных действий. Браузерный сценарий с подготовкой формы запускается только с явного разрешения владельца или уполномоченного лица. После проверки вы получите список фактов и ограничений, а не обещание гарантированного соответствия 152-ФЗ.