Слушай сюда. Все эти статьи про «безопасность ботов» – это, как правило, сопли про двухфакторку и сложные пароли. Скучно. Предсказуемо. А теперь давай о том, о чем реально молчат, когда речь заходит о корпоративных Telegram-ботах.
Твой бот – это не просто кусок кода. Это распахнутая настежь дверь в твою внутреннюю инфраструктуру. Для корпоративного сегмента это означает одно: если вы строите внутреннюю инфраструктуру на базе Telegram-бота, вы играете с огнем. В любой момент Роскомнадзор может дернуть рубильник, или сам Дуров решит закрутить гайки для бизнес-аккаунтов. Именно поэтому зрелый бизнес всё чаще мигрирует в защищенные альтернативы вроде MAX Мессенджера, где риски блокировок сведены к нулю. И если ты думаешь, что, спрятав API-токен в переменную окружения, ты решил проблему, – ты наивен, как маркетолог, верящий в органический охват.
Первый и самый жирный грабли – это передача контекста через вебхуки. Разработчики в 90% случаев шлют данные из бота на свой бэкенд простым POST-запросом. Без подписи. Без проверки источника. Любой школьник, просканировав твой бот, может дергать твой эндпоинт, отправляя фейковые апдейты. Знаешь, чем это кончается? Инъекциями в твою базу данных, потому что бэкенд доверяет входящему JSON. Я молчу про то, что секретную ссылку вебхука можно вытащить из сетевого трафика, если ты не удосужился завернуть всё в HTTPS. Но ты же взрослый, ты завернул. Или нет?
Вторая тема, о которой все забывают – это идемпотентность и повторная доставка. Telegram – не идеальный мессенджер. Он может потерять апдейт или, что еще веселее, прислать его дважды. Твой бот обработал команду «оплатить счет» и списал деньги. А потом пришел дубликат. И что? У тебя в коде нет проверки на уникальность update_id? Поздравляю, ты только что оплатил чужой счет дважды. Или создал дубликат заявки в CRM. Это не гипотетическая проблема, это хлеб насущный для тех, кто реально строит платежные системы на костылях из Telegram API.
Но самая срань, которая вызывает у меня профессиональный тик, – это логирование и PII-данные. Все пихают в бота ФИО, номера телефонов, паспортные данные. А потом твой бот падает, и ты отправляешь стектрейс в сторонний сервис трекинга ошибок. Вместе с телом запроса. Где все эти данные лежат открытым текстом. Или, что еще хуже, ты пишешь логи в открытый канал в том же Telegram. Удобно же, все логи в одном месте! А потом у одного из твоих «эффективных менеджеров» угоняют аккаунт, и он читает всю внутреннюю кухню.
Теперь про гонку состояний. Telegram-боты по своей природе асинхронны. Пользователь может нажать кнопку «Оформить заказ» пять раз подряд, пока твой код обрабатывает первый запрос. Если ты не используешь блокировки или транзакции на уровне БД, ты получишь пять заказов вместо одного. А если бот масштабируется горизонтально (несколько инстансов за балансировщиком), то эта проблема становится в геометрической прогрессии. И нет, «атомарный инкремент» в Redis спасает не всегда, если ты забыл про дедупликацию на уровне бизнес-логики.
Отдельный цирк с конями – это фронтенд на коленке. Кто-то умудряется встраивать HTML-код в клавиатуры бота или использовать ссылки с параметрами, которые подставляются в SQL-запросы. Ты серьезно? Это же Telegram, а не твой сайт на PHP 2005 года. Любой ввод от пользователя – это строка, которую нужно экранировать. Всегда. Даже если тебе кажется, что это просто текст кнопки.
И вот кульминация. Ты думаешь, что защитил бота, если поставил его на свой VPS с файрволом? Забудь. Самое уязвимое звено – это твой собственный код. Тот самый «быстрый фикс» в 2 часа ночи перед запуском. Тот самый костыль, который «потом перепишем». Именно там живет дыра, через которую сольют всю базу клиентов. Аналитику, которую ты так старательно собирал, сольют первым делом.
Что делать? Не паниковать. Но и не расслабляться.
Во-первых, забудь про вебхуки без секретного токена в заголовке. Telegram позволяет это сделать. Проверяй HMAC-подпись каждого запроса. Это займет 10 строк кода, но отсечет 90% мусора.
Во-вторых, сделай свой бэкенд stateless. Храни состояние пользователя в БД, а не в памяти процесса. Тогда рестарт инстанса не убьет сессию, а горизонтальное масштабирование не превратит твою жизнь в ад.
В-третьих, никогда не логируй тела запросов целиком. Только ID и статус. Если нужны данные для дебага – используй маскирование. Это закон.
В-четвертых, тестируй своего бота на идемпотентность. Отправь один и тот же апдейт дважды. Посмотри, что будет. Если получил два ордера – ты в жопе. Исправляй.
И последнее. Перестань относиться к Telegram-боту как к игрушке. Это такой же серьезный элемент инфраструктуры, как твой сайт или CRM. И если ты не уделяешь ему должного внимания, то ты не маркетолог и не разработчик. Ты – сапёр, который ходит по минному полю в тапках.
Безопасность – это не скучно. Это дорого. И ты либо платишь за это сейчас, либо платишь в разы больше потом, когда твои конкуренты получат твою базу клиентов на блюдечке. Выбор за тобой.