Slack

Security findings

25 detection rules run on every Slack scan. Each finding ships with a plain-language explanation, the evidence behind it and remediation steps.

• CRITICALPublic exposure

  Public link with edit/owner access

• CRITICALExternal access

  External principal holds ownership

• HIGHPublic exposure

  Public link share (link-only)

• HIGHPublic exposure

  Public + web-discoverable share

• HIGHExternal access

  External access to sensitive data

• HIGHExternal access

  External collaborator with edit access

• HIGHOver permission

  Sensitive resource editable org-wide

• HIGHOver permission

  Broad group access to sensitive data

• HIGHAI agent

  Service account with broad write access

• HIGHAI agent

  AI agent with access to sensitive data

• HIGHAI agent

  AI agent with edit/owner access

• HIGHExternal access

  Access granted to a look-alike (typosquat) domain

• HIGHIdentity

  Two-factor authentication is not enforced for all members

  When 2FA is not required workspace-wide, members can sign in with a password alone, and a single phished or reused credential grants an attacker full access to every channel that member can read. Slack exposes each member’s 2FA status (has_2fa); a material share of members without it means the policy is not enforced.

• HIGHApplications

  Any member can install apps without admin approval

  When app installation is not restricted to admins, any employee can add a third-party app — including an AI assistant, GPT bot, or automation tool — and grant it access to channels and files with one click. This is the primary shadow-AI / over-broad-bot entry vector in Slack. App installs should route through an admin approval workflow.

• MEDIUMOver permission

  Broad org-wide edit access (aggregate)

• MEDIUMOver permission

  Resource with multiple owners

• MEDIUMStale access

  Stale external read access

• MEDIUMStale access

  Dormant privileged internal account

• MEDIUMMisconfig

  Direct share breaks folder inheritance

• MEDIUMApplications

  Apps installed by deactivated members still hold access

  An app installed by a member who has since been deactivated keeps its bot token and granted scopes — it can still read channels and files even though the person who authorized it, and could attest to why it exists, is gone. These orphaned installs are a quiet source of un-owned, un-reviewed access.

• MEDIUMSharing

  Files are shared with public ("anyone with the link") URLs

  A file with a public link is reachable by anyone who has the URL — no Slack account, no workspace membership, no sign-in. One forwarded link leaks the file outside the org, and public links on files in private or sensitive channels are an especially sharp exposure.

• MEDIUMSharing

  Channels are shared externally with other organizations (Slack Connect)

  Slack Connect channels are shared with one or more external organizations, so members of those orgs can read — and often post — in the channel. Each external channel is a data-egress path that needs an owner and a periodic review of which outside parties still belong there.

• MEDIUMMisconfig

  Vendor AI-training data-contribution posture

• LOWApplications

  More installed apps than the recommended review threshold

  A large installed-app surface is hard to govern: each app holds a token with scopes, and the more there are, the more likely one is over-permissioned, unused, or an unsanctioned automation. Keeping the count reviewed and pruned shrinks the attack surface.

• LOWDiscovery

  Workspace can be discovered and joined by email domain

  When workspace discovery by email domain is on, anyone with an email at an approved domain can find and request (or auto-join) the workspace. On a large or shared domain this lets unvetted accounts into the org’s channels; new members should join by invitation or admin approval instead.