Your bot token lets anyone read your users' messages and speak as your bot. This page describes exactly how we protect it — and what we have not built yet.
Your Telegram bot token is a full credential for your bot, so it is sealed with AES-256-GCM before it touches the database or a backup, decrypted only to call Telegram, never logged, and shown masked everywhere in the product.
HTTPS with TLS 1.2+ for every connection, enforced with HSTS. Bot tokens and two-factor secrets are encrypted at rest with a key held only by your deployment.
Passwords hashed with scrypt, opt-in TOTP two-factor with recovery codes, httpOnly session cookies with CSRF protection, rate limiting on sign-in and password reset, and automatic lockout after repeated failures.
Five workspace roles from owner to viewer, enforced on the server for every request — not just hidden in the interface. Staff access to a customer workspace is possible only through impersonation, which is always recorded.
Sign-ins, bot changes, publishes, billing events, team changes, and staff impersonation are written to an append-only audit log you can read in your console.
Nightly encrypted database backups with configurable retention and a documented, tested restore procedure. Bot connections are checked every few minutes and reconnected automatically if Telegram drops them.
We run on OVH and Hetzner, hosting providers audited to recognized data-center security and compliance standards. On top of that, we run our own server-level security testing and commission third-party penetration testing and independent verification of the system as a whole.
Plenty of vendors leave this section out. We would rather you could plan around it.
| Area | Control |
|---|---|
| Encryption in transit | TLS 1.2+ everywhere, HSTS enabled |
| Secrets at rest | AES-256-GCM for bot tokens and 2FA secrets |
| Passwords | scrypt (N=32768), constant-time verification |
| Sessions | Opaque 256-bit tokens, httpOnly cookies, stored hashed, 30-day rolling expiry |
| Browser hardening | Content-Security-Policy, X-Frame-Options, nosniff, strict referrer policy |
| Abuse prevention | Rate limiting on authentication, password reset, and public forms |
| Authorization | Role checks enforced server-side on every request |
| Audit trail | Append-only log of account, bot, billing, and staff actions |
| Backups | Nightly encrypted dumps, configurable retention, documented restore drill |
| Dependencies | Locked dependency versions installed from the public npm registry only |
| Infrastructure | OVH and Hetzner data centers, independently audited |
| Penetration testing | Commissioned third-party testing plus ongoing independent verification |
If you believe you've found a security vulnerability in Meshwire, please report it privately so we can investigate and respond before any public disclosure. We acknowledge reports within 24 hours and aim to resolve critical issues within 7 days. We do not pursue legal action against good-faith researchers who follow this policy.