Skip to content
On This Page
  • 1. Security Overview

  • 2. System Architecture

  • 3. SOC2 Compliance

  • 4. Authentication & Access

  • 5. Encryption

  • 6. Rate Limiting & DoS Protection

  • 7. Audit Logging

  • 8. Vulnerability Management

  • 9. Certifications & Attestations

  • 10. Application Permissions

  • 11. Security Contact

Security & Compliance

Last updated: September 26, 2026

1. Security Overview

SlackBridge is built with enterprise-grade security at its core. We implement comprehensive security controls aligned with SOC2 Trust Service Criteria to protect your data and ensure reliable service delivery.

SOC2-Aligned Controls

We have implemented controls aligned with SOC2 Trust Service Criteria across Security, Availability, and Confidentiality. Formal audit has not yet been completed.


2. System Architecture

SlackBridge operates as a serverless message relay running on Cloudflare's global edge network. Messages are relayed in real-time. Full message content is not stored; only minimal metadata is temporarily retained for thread synchronization.

SlackWorkspaceEvents APIHMAC-SHA256 signedCloudflare WorkersSlackBridge APIProprietary Message Routing& Format TranslationTLS 1.3In TransitEncryptedAES-256OAuth TokensAt RestMessages NOT StoredReal-time relay onlyMicrosoft TeamsChannelBot FrameworkJWT verifiedSlack originatedTeams originatedTLS encrypted
Key Security Properties
  • No message content at rest: Full messages are relayed in real-time and are never written to disk. To keep reply threads in sync, we retain for 7 days only routing metadata (message and channel identifiers, timestamps, and a non-reversible one-way fingerprint of the message), never the readable message text or sender name. These records auto-delete after 7 days.
  • Edge processing: Requests are handled at the nearest Cloudflare data center (300+ locations)
  • Encryption in transit: TLS 1.3 secures all connections between Slack, SlackBridge, and Teams. SlackBridge relays between two separately encrypted connections and processes the message in between, so this is transport encryption, not end-to-end encryption
  • Isolated execution: Each request runs in an isolated V8 context with no shared state

3. SOC2 Compliance Status

We have implemented controls aligned with the AICPA SOC2 framework. Below is our current compliance status:

Authentication

Multi-layer verification for all platform integrations

Authorization

Role-based access control with least-privilege principles

Encryption

Industry-standard encryption for data in transit and at rest

Rate Limiting

Adaptive rate limiting to prevent abuse

CSRF & Replay Protection

Request validation and deduplication

Audit Logging

Comprehensive event logging with plan-based retention

Input Validation

Strict validation and sanitization of all inputs

Monitoring

Health endpoints and Cloudflare analytics for availability tracking

Detailed Documentation: Complete technical specifications and documentation of our implemented security controls are available to enterprise customers under NDA. Contact security@slackbridge.com to request access.


4. Authentication & Access Control

SlackBridge implements multi-layer authentication to verify requests from both Slack and Microsoft Teams platforms.

4.1 Platform Integration Security

  • Cryptographic signature verification for all incoming webhooks
  • Token validation following platform security best practices
  • App identity verification to prevent request forgery
  • Timestamp validation and replay attack protection

4.2 Dashboard Access

  • OAuth 2.0 with PKCE for secure authentication
  • Server-side session management with configurable expiration
  • CSRF protection on all state-changing operations
  • API key authentication for programmatic access

5. Encryption

SlackBridge uses industry-standard encryption to protect data both in transit and at rest.

5.1 Data in Transit

  • Modern TLS encryption for all connections
  • HSTS (HTTP Strict Transport Security) enabled
  • Automatic certificate management and renewal

5.2 Data at Rest

  • Strong encryption for stored OAuth tokens and credentials
  • Unique initialization vector for each encryption operation
  • Encryption keys managed as secrets, never in source code

5.3 Message Content

Important: Full message content is never stored on our servers. Messages are relayed in real-time through our serverless infrastructure. To enable thread synchronization, we retain for 7 days only routing metadata (message and channel identifiers, timestamps, and a non-reversible one-way fingerprint, or BLAKE3 hash, of the message), after which it is automatically deleted. That record never contains the readable message body or the sender's name; display names and avatar images are cached separately for up to 24 hours so relayed messages show who sent them, and each bridged channel with mentions turned on keeps a member list (display names and user IDs) until that channel mapping is deleted. Operational logs record identifiers, timings and error details. They never include the text of bridged messages or the names of people in bridged conversations; events about your account can include the account holder's email address. Cloudflare keeps these logs for up to 7 days. When an error occurs, an error report containing the error, the request method and path, and the most recent log lines (never the request body, headers or query string) is sent to our error-monitoring sub-processor, Sentry, which keeps it for up to 90 days. Connection and consent audit events, which contain no message content, are retained for 30 days on the Free plan and 90 days on the Pro plan.


6. Rate Limiting & DoS Protection

SlackBridge implements adaptive rate limiting to protect against abuse while ensuring legitimate traffic flows smoothly.

  • Per-endpoint limits: Different rate limits for message events, API calls, and authentication
  • Sliding window algorithm: Smooth rate limiting that prevents bursting
  • Graceful degradation: System maintains availability even under stress
  • Abuse detection: Automated blocking of suspicious traffic patterns

Rate limits are calibrated to support normal business usage while preventing abuse. Enterprise customers can request limit adjustments based on their needs.


7. Audit Logging

SlackBridge keeps audit records of security and connection events for monitoring and compliance purposes.

7.1 Events Logged

  • Authentication failures: Rejected Slack request signatures and rejected Microsoft Teams bot tokens
  • Security events: Rate limiting, replay detection, CSRF failures
  • Consent and connection events: Microsoft admin consents, connection deletions, channel creation and bot reinstalls

Operational logs capture identifiers and error details, never the text of bridged messages or the names of people in bridged conversations. Error paths that handle Microsoft Teams bot tokens and service URLs pass through a redaction step that replaces token-shaped strings before they are logged.

7.2 Log Integrity

  • Hash-chained events: On Pro plans, consent and connection events are written as a hash chain, each event carrying the hash of the one before it, so changing or removing an event in the middle of the chain breaks verification unless every later event is rewritten as well
  • Object-locked copy: Security audit events (authentication failures, rate limiting, replay and CSRF detections) are mirrored to Cloudflare R2 under a 90-day object lock that the storage layer enforces against overwrite and deletion. A separate low-latency store serves queries
  • Retention by plan: Consent and connection events are kept for 30 days on Free and 90 days on Pro; security audit events are kept for 90 days on every plan

8. Vulnerability Management

SlackBridge follows security best practices to identify and remediate vulnerabilities.

  • Code review: Multiple review layers including automated security scanning
  • SSRF protection: Strict URL validation and request restrictions
  • Input validation: Comprehensive validation of all user inputs and webhooks
  • Secure comparisons: Protection against timing-based attacks
  • Error handling: Secure error responses that don't leak internal details
  • Dependency management: Regular updates and security patch monitoring

9. Certifications & Attestations

SlackBridge has implemented controls mapped to the SOC 2 Trust Services Criteria. SlackBridge does not yet hold its own SOC 2 Type II or ISO 27001 attestation; an independent third-party audit is on our roadmap. Our underlying infrastructure is operated by certified providers (see 9.2).

9.1 SlackBridge Controls

  • Security: Comprehensive authentication, encryption, and abuse prevention controls
  • Availability: Health monitoring, graceful degradation, and redundancy measures
  • Confidentiality: Data encryption, access logging, and secure storage

9.2 Infrastructure Certifications

SlackBridge runs on Cloudflare's globally distributed infrastructure, which maintains:

  • SOC 2 Type II
  • ISO 27001
  • PCI DSS Level 1
  • GDPR compliant

10. Application Permissions

SlackBridge offers two setup methods for connecting Microsoft Teams. Each method requests a different set of Microsoft Graph API permissions from your tenant administrator.

10.1 Slack Permissions

SlackBridge requests the following Slack bot scopes when you connect your workspace. These are the same regardless of which Microsoft setup method you choose.

ScopePurpose
channels:readList public channels for mapping selection
channels:historyFetch new messages in public channels for real-time relay
channels:manageCreate and configure bridged channels
channels:joinJoin public channels selected for bridging
groups:readList private channels for mapping selection
groups:historyFetch new messages in private channels for real-time relay
groups:writeCreate and configure private bridged channels
chat:writePost bridged messages from Teams into Slack
chat:write.customizeDisplay the original Teams sender name and avatar
users:readResolve Slack user profiles for display in Teams
users:read.emailMatch Slack users by email for member invites
reactions:readDetect reactions added in Slack so they can be bridged to Teams
reactions:writeAdd bridged reactions from Teams onto Slack messages, as the bot only
files:readRead a file shared in a bridged Slack channel so it can be copied to Microsoft Teams
files:writeUpload a file shared in Microsoft Teams into the bridged Slack channel, as the bot only

Messages are never stored. SlackBridge relays messages in real-time between platforms. Only routing metadata (message and channel identifiers, timestamps, and a non-reversible one-way fingerprint) is retained for 7 days for thread synchronization, never the readable message text or sender name.

10.2 Core Bridging - Microsoft Permissions (6 application permissions)

Formerly called Secure Connect.

Requests 6 read-focused permissions. Your client's IT admin adds the SlackBridge bot to Teams manually.

PermissionTypePurpose
Group.Read.AllApplicationList available teams for channel mapping selection
Channel.ReadBasic.AllApplicationFetch channel names and descriptions within teams
Channel.CreateApplicationCreate the bridged channel in the selected team
ChannelMessage.Read.AllApplicationReceive message notifications for real-time relay
Team.ReadBasic.AllApplicationFetch team properties (name, description) for display
User.Read.AllApplicationResolve message author display names and avatars

10.3 Full Integration - Microsoft Permissions (11 application permissions)

Formerly called Guided Setup.

Includes all 6 standard permissions, 4 additional permissions for automated bot installation and team management, and Sites.Selected, which grants nothing until your administrator grants a specific channel site.

PermissionTypePurpose
Group.Read.AllApplicationList available teams for channel mapping selection
Channel.ReadBasic.AllApplicationFetch channel names and descriptions within teams
Channel.CreateApplicationCreate the bridged channel in the selected team
ChannelMessage.Read.AllApplicationReceive message notifications for real-time relay
Team.ReadBasic.AllApplicationFetch team properties (name, description) for display
User.Read.AllApplicationResolve message author display names and avatars
Group.ReadWrite.All
Full Integration only
ApplicationManage team settings and channel configuration
AppCatalog.ReadWrite.All
Full Integration only
ApplicationUpload SlackBridge bot app to your tenant catalog
TeamsAppInstallation.ReadWriteForTeam.All
Full Integration only
ApplicationAutomatically install the bot into selected teams
TeamMember.ReadWrite.All
Full Integration only
ApplicationManage team membership for bridge participants
Sites.Selected
Full Integration only
ApplicationGrants nothing by itself. Lets your SharePoint administrator grant SlackBridge read access to one named private or shared channel site at a time, so files posted there can be copied to Slack. Every channel site is a separate grant made with your own tooling; SlackBridge never holds the tenant-wide permission that making a grant requires.

Revocable after setup: The four additional Full Integration permissions (Group.ReadWrite.All, AppCatalog.ReadWrite.All, TeamsAppInstallation.ReadWriteForTeam.All, TeamMember.ReadWrite.All) are exercised during admin-initiated setup operations. Three of the four are not used at runtime. The exception is Group.ReadWrite.All, which is also used at runtime on any connection with file sharing on: copying a file in either direction reads and writes it through the channel's document library. Once initial setup is complete, your tenant administrator can revoke these four permissions in Azure AD → Enterprise Applications → SlackBridge → Permissions and ongoing message bridging continues uninterrupted on the six Core Bridging permissions alone. Revoking them does stop file copying, which then falls back to announcing each file by name and type; if you want that, turning file sharing off for the connection in the SlackBridge dashboard is the cleaner way. You would need to re-grant them to auto-create another Team or auto-install a bot manifest update. The eleventh permission, Sites.Selected, reaches nothing until your administrator grants a specific channel site and can be revoked the same way at any time.

Note: Both tiers require admin consent from your Microsoft 365 tenant administrator. All permissions are application-level (not delegated) and follow Microsoft's least-privilege recommendations. SlackBridge does not request ChannelMessage.Send as message delivery is handled securely through the Azure Bot Framework.


11. Security Contact

To report a security vulnerability or request security documentation:

Email: security@slackbridge.com
Response Time: Critical issues within 24 hours