Безопасность мини-приложений Telegram: проверка данных пользователя

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

Данные запуска и их подпись

При открытии мини-приложения Telegram передаёт строку данных запуска — initData. В ней информация о пользователе, время авторизации и подпись. В SDK эти же данные доступны в уже разобранном виде, но этот вариант никак не защищён и подходит только для отображения, например чтобы показать имя пользователя на экране.

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

Как проверяется подпись

Проверка выполняется на сервере с использованием токена бота, который никогда не попадает во фронтенд. Из строки данных убирается поле с подписью, остальные поля сортируются по имени и соединяются в одну строку по правилам, описанным в документации Telegram. Затем вычисляется HMAC-SHA256 с секретным ключом, полученным из токена бота, и результат сравнивается с переданной подписью. Если не совпадает — запрос отклоняется.

Используйте проверенные библиотеки для своего языка, которые реализуют эту процедуру, и не пишите её на ходу: ошибки в деталях делают проверку бесполезной. Кроме того, Telegram предусматривает проверку данных и третьими сторонами по публичному ключу, без токена бота — это пригодится, если данные пользователя нужно передать внешнему сервису.

Срок действия данных

В данных запуска есть время авторизации. Сервер должен отклонять слишком старые данные, иначе перехваченная строка будет работать бесконечно. Допустимый срок выбирают исходя из сценария: для платежей и чувствительных операций — короткий.

Сессии

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

Защита API

• Каждый запрос проверяет, что пользователь имеет право на этот ресурс: заказ, профиль, документ
• Цены, скидки и итоговая сумма рассчитываются на сервере, а не берутся из фронтенда
• Ограничение частоты запросов от одного пользователя
• Проверка и очистка всех входящих данных
• HTTPS для всех запросов

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

Токен бота и секреты

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

Платежи

Факт оплаты подтверждается только уведомлением платёжного сервиса на сервер или проверкой статуса через API провайдера, а не сообщением фронтенда «оплата прошла». Заказ переводится в оплаченные после серверной проверки суммы и идентификатора платежа.

Персональные данные

Запрашивайте у пользователя только то, что нужно для услуги. Номер телефона — через официальный запрос с согласия, а не через скрытые механизмы. Опубликуйте политику обработки данных и храните их с учётом требований законодательства Узбекистана. Журналы сервера не должны содержать лишних персональных данных и строк initData целиком.

Регулярная проверка

Перед запуском и после крупных изменений попросите независимого специалиста проверить API: попробовать обратиться к чужим данным, подменить сумму заказа, отправить запрос без подписи или со старыми данными. Такая проверка занимает немного времени и находит ошибки, которые разработчик не замечает в собственном коде.