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.
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.
| Scope | Purpose |
|---|---|
| channels:read | List public channels for mapping selection |
| channels:history | Fetch new messages in public channels for real-time relay |
| channels:manage | Create and configure bridged channels |
| channels:join | Join public channels selected for bridging |
| groups:read | List private channels for mapping selection |
| groups:history | Fetch new messages in private channels for real-time relay |
| groups:write | Create and configure private bridged channels |
| chat:write | Post bridged messages from Teams into Slack |
| chat:write.customize | Display the original Teams sender name and avatar |
| users:read | Resolve Slack user profiles for display in Teams |
| users:read.email | Match Slack users by email for member invites |
| reactions:read | Detect reactions added in Slack so they can be bridged to Teams |
| reactions:write | Add bridged reactions from Teams onto Slack messages, as the bot only |
| files:read | Read a file shared in a bridged Slack channel so it can be copied to Microsoft Teams |
| files:write | Upload 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)
Requests 6 read-focused permissions. Your client's IT admin adds the SlackBridge bot to Teams manually.
| Permission | Type | Purpose |
|---|---|---|
| Group.Read.All | Application | List available teams for channel mapping selection |
| Channel.ReadBasic.All | Application | Fetch channel names and descriptions within teams |
| Channel.Create | Application | Create the bridged channel in the selected team |
| ChannelMessage.Read.All | Application | Receive message notifications for real-time relay |
| Team.ReadBasic.All | Application | Fetch team properties (name, description) for display |
| User.Read.All | Application | Resolve message author display names and avatars |
10.3 Full Integration - Microsoft Permissions (11 application permissions)
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.
| Permission | Type | Purpose |
|---|---|---|
| Group.Read.All | Application | List available teams for channel mapping selection |
| Channel.ReadBasic.All | Application | Fetch channel names and descriptions within teams |
| Channel.Create | Application | Create the bridged channel in the selected team |
| ChannelMessage.Read.All | Application | Receive message notifications for real-time relay |
| Team.ReadBasic.All | Application | Fetch team properties (name, description) for display |
| User.Read.All | Application | Resolve message author display names and avatars |
| Group.ReadWrite.All Full Integration only | Application | Manage team settings and channel configuration |
| AppCatalog.ReadWrite.All Full Integration only | Application | Upload SlackBridge bot app to your tenant catalog |
| TeamsAppInstallation.ReadWriteForTeam.All Full Integration only | Application | Automatically install the bot into selected teams |
| TeamMember.ReadWrite.All Full Integration only | Application | Manage team membership for bridge participants |
| Sites.Selected Full Integration only | Application | Grants 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