Security and data handling

A bridge sits in the middle of two companies' conversations, which is a position that has to be earned. This page describes what ThreadBridge holds, what it doesn't, and how the connections are protected.

Credentials

• Slack bot tokens and Microsoft access and refresh tokens are encrypted at rest in the database, and are never displayed in the interface.
• Tokens are sent to the runtime when a bridge starts, authenticated with a shared secret checked with a constant-time comparison on both ends, and held in the memory of that bridge's processes while it runs.
• Disconnecting Slack revokes the token with Slack and deletes it here. Disconnecting Teams deletes the stored credential, and consent can be withdrawn independently from the Microsoft Entra admin center.

Message content

ThreadBridge relays messages; it isn't an archive.

• Message text is not written to the database. It exists in memory long enough to be delivered to the other platform.
• The loop-prevention registry stores a SHA-256 fingerprint, not the text, for thirty seconds, in memory only.
• The mapping between the two platforms' message IDs is stored durably, so it survives a runtime restart or deploy instead of being rebuilt from scratch, and is retained for 30 days. It contains identifiers only (which platform, which message ID), never the message text.
• Bridge events recorded against your account describe the bridge's lifecycle (started, stopped, restarted, health checks, errors), not the messages that passed through it. They are retained for 7 days on Free and 90 days on the paid plan; routine health checks for 7 days on every plan.
• Application logs and error reports record identifiers (bridge, channel, message ID) and error codes. Message text, author names, and credentials are redacted before anything is logged, including when a process crashes.

The messages themselves live where they were posted, under your Slack and Microsoft 365 retention policies, exactly as if the two sides had been typed by hand.

Webhook verification

• Every Slack request is verified with an HMAC-SHA256 signature over the raw request body and timestamp, using the app's signing secret. Unsigned or mismatched requests are rejected.
• Slack requests older than five minutes are rejected outright, so a captured request can't be replayed later.
• Microsoft Graph notifications carry a client state value that ThreadBridge set when it created the subscription; a notification arriving without the right value is rejected.
• Graph subscription validation handshakes are answered only for endpoints the runtime itself created.

Isolation between customers

• A Slack workspace or Microsoft tenant can be connected to exactly one ThreadBridge account. This is enforced in the database, because inbound events are routed by workspace and a shared claim would mean delivering one company's messages into another's bridge.
• Each running bridge is a separate supervised process tree. A crash, a revoked token, or a deleted channel affects that bridge and nothing else.
• Bridges and connections are scoped to the account that owns them.

Access within your account

ThreadBridge accounts are teams. Members you invite can see the bridges on the account; administrative actions are limited to account admins. Removing someone from the account removes their access to it.

Scope minimization

ThreadBridge asks for the narrowest permissions the platforms offer for this job: list channels, read messages, post messages. It requests no access to directories, mailboxes, calendars, files, or direct messages. Where a platform offers only a broad permission, such as Microsoft Graph's tenant-wide channel-message permissions, the runtime narrows it itself by subscribing only to the channels in a bridge's map.

Reporting something

If you believe you've found a vulnerability, email support@threadbridge.app with enough detail to reproduce it. We'd rather hear about it early and awkwardly than late.