Running it

Telegram bot security: the mistakes that actually cause incidents

By the Botable team

Most Telegram bot incidents come from five places: a leaked token, admin commands that anyone can run because nothing checks who sent them, an unverified webhook endpoint accepting forged updates, unvalidated input reaching a database query, and storing far more personal data than the bot needs.

The short version

Telegram bot security has a small and well-understood failure surface, and nearly every real incident comes from one of five places. A leaked token is the worst, because it is a bearer credential with no scope — whoever has it can read every message, send as the bot, and repoint its webhook. Missing authorisation on admin commands is the most common: a /broadcast that checks nothing lets any user message your entire audience, and the bot cannot tell an admin from anyone else unless you compare the sender against a list. Unverified webhook endpoints accept forged updates from anyone who finds the URL. Unvalidated input reaching a database query is the same injection problem as anywhere else, made likelier because chat input feels conversational rather than hostile. And retaining message history indefinitely turns a small breach into a large one. None of these are exotic; all five are checklist items.

Step by step

How should the token be handled?

Environment variable or secrets manager, never in source control, never in a screenshot, never pasted to someone helping you debug. Rotate it with /revoke the moment you suspect exposure, and plan the swap across every running instance in advance.

How do you protect admin commands?

Compare the sender's numeric user id against an allowlist inside the handler, on every privileged command. Not the @username, which is mutable. This is the single most common bot vulnerability, and it is three lines.

How do you secure a webhook endpoint?

Register a secret token with the webhook and verify it on every incoming request, so forged posts are rejected. The endpoint is public by necessity; without verification anyone who guesses the URL can inject updates that your bot will treat as genuine.

What about input and stored data?

Treat every message as untrusted: parameterised queries, length limits, and validation before anything reaches storage or a shell. Then keep only what you need and delete it on a schedule — data you never stored is the only data that cannot leak.

What catches people out

  • Checking @username instead of user id for admin access is bypassed by anyone who claims the username
  • A webhook without secret verification accepts forged updates from anyone
  • Indefinite message retention converts a minor incident into a major disclosure

Questions

Can other people read my bot's messages?

Only whoever holds the token, or anyone in a group where the bot is present reading normally. Bot conversations are not end-to-end encrypted, which is worth stating plainly if your bot handles anything sensitive.

Is it safe to accept files from users?

With care. Validate type and size, never execute anything received, and store uploads outside any path that gets served. A bot that accepts documents is a file upload endpoint with a friendlier interface.

Want a bot that does this?

Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you — the token, the webhook, the storage, the hosting.

Build a bot

Keep reading

Bots that use this

All twenty-five guides