Securing bot tokens: storage, rotation and what to do after a leak

Why tokens deserve special care

Platform tokens grant full control of the bot account. With a Telegram bot token, anyone can read updates sent to the bot and send messages as it. A Discord bot token can act in every server the bot joined, with every permission it was granted. A Slack bot token carries all of the app's scopes in that workspace.

Leaks are rarely dramatic. They come from a .env committed by accident, a screenshot in a support chat, a log line that prints the request URL (Telegram tokens are part of the URL), or a public CI log.

Store them properly

• Never in code or the repository. Use your host's secret store or environment variables injected at runtime.
• Separate per environment. Development, staging and production each get their own bot and token. A leaked test token should not touch real users.
• Keep them out of URLs and logs. Redact tokens in your logger and in error reports. Our token helper scans text for common token formats before you paste it anywhere.
• Limit who can read them. In CI, scope production secrets to the production deployment job only.

Grant the minimum

The damage from a leak equals the permissions you granted. Request only the Discord permissions and intents you use, only the Slack scopes you need, and admin rights in Telegram groups only when the bot moderates. The permissions calculator builds minimal invites and manifests.

Detect leaks early

• Enable secret scanning and push protection on your repositories. GitHub's push protection blocks commits that contain supported token formats.
• Several platforms take part in GitHub's secret scanning partner program, which lets the provider be notified when its tokens appear in public repositories; Discord and Slack are among the listed partners. Do not rely on it: scan before you push.
• Add a scanner such as Gitleaks or TruffleHog to CI.
• Alert on unusual bot behavior: messages you did not send, webhook URLs you did not set, sudden 401 errors (someone else may have rotated the token).

Rotate without downtime

Plan rotation before you need it:

1. Make the bot read its token from configuration at startup, never from code.
2. Generate a new token on the platform.
3. Update the secret in your host and restart or redeploy.
4. Confirm the bot works, then make sure the old token is invalid.

Most bot platforms invalidate the old token as soon as you generate a new one (Telegram's /revoke, Discord's Reset Token), so steps 2 and 3 should happen within minutes. For webhook secrets that you control, support two valid secrets during a short overlap.

If a token leaked: the checklist

1. Revoke first. Telegram: /revoke in @BotFather. Discord: Developer Portal, Bot, Reset Token. Slack: rotate or reinstall in the app settings. GitHub: delete the token.
2. Deploy the new token from your secret store.
3. Check what happened during the exposure: messages sent, webhook URL changes (Telegram getWebhookInfo), servers joined, files accessed.
4. Find the cause and fix it: add the file to .gitignore, redact the logger, tighten CI secret scopes.
5. Rewrite history only after rotating. Forks, clones and caches keep the old commit, so a rewritten history does not undo the leak.
6. Tell affected users if their data could have been read.

Webhook secrets are tokens too

Telegram's secret_token, Slack's signing secret and Meta's app secret prove that requests come from the platform. Treat them with the same care, compare signatures in constant time, and reject requests with old timestamps.

Sources

• Telegram BotFather and token revocation: core.telegram.org/bots/features#botfather
• GitHub push protection: docs.github.com/code-security/secret-scanning/introduction/about-push-protection
• GitHub secret scanning partner list: docs.github.com/code-security/secret-scanning/introduction/supported-secret-scanning-patterns
• Slack, verifying requests: api.slack.com/authentication/verifying-requests-from-slack
• Our guide: Bot security