Home
IT Hub
Slack

Slack Security Concerns: What Technical Teams Need to Know

Reco Security Experts
Updated
May 14, 2025
May 15, 2025

Slack is the go-to platform for nearly every technical team's internal communication. But convenience is not without risk. As of 2024, Slack has 38.8 million daily active users and 65 million monthly active users, reflecting its widespread adoption in the business communication sector. The more people use Slack, the more security pains come along for the ride, especially for large organizations with sensitive code, data, and infrastructure details flying around via chat.

This article covers the main Slack security concerns that technical teams must be aware of, with clear guidance on how to manage these risks. We’ll look into identity and access risks, token misuse, app integrations, data retention, compliance, and more.

Identity and Access Management (IAM) Risks

Managing user access in Slack is the first layer of defense, but it is often not well controlled. Teams usually integrate Slack with identity providers like Okta or Azure AD, but misconfigurations can leave gaps. Former employees may retain access if identity provider syncs are misconfigured or not regularly monitored. Unrevoked sessions or shared credentials—against best practices—can allow unauthorized access to sensitive channels.

Many times, guest and multi-channel guest accounts are not properly checked. These accounts are intended for temporary access but are rarely reviewed. If technical discussions happen in shared channels with guests, source code snippets, internal links, or API keys might be unintentionally exposed. Teams should enforce strict SSO (Single Sign-On) policies, automatically revoke Slack tokens for offboarded users, and perform quarterly access reviews.

API Tokens and Bot Tokens Misuse

Slack bots and custom applications are capable, but they are full of security weaknesses. They use OAuth tokens, which, if leaked, can lead to security issues. They are given wide scopes most of the time, i.e., reading messages, accessing files, or even editing channels. Slack bot tokens have appeared in GitHub leaks and public repositories due to hardcoded secrets and poor secret hygiene.

Developers sometimes hardcode these tokens in scripts or CI/CD pipelines. If these scripts are committed to a repository without filtering secrets, attackers can extract the tokens and silently join or monitor Slack channels.

How token details can be exposed when shared in Slack, using Postman as an illustrative example.

Access token settings in Postman Bot Token, highlighting a user token and scope under "Token Details" with a red arrow pointing to the exposed token string in String.

All technical teams should:

  • Use secret managers for storing tokens
  • Rotate tokens regularly
  • Audit app scopes to avoid excessive permissions

App Integrations and Third-Party Risks

Many teams connect Slack with tools like Jenkins, GitHub, PagerDuty, and JIRA to receive alerts and automate actions. However, each app integration expands the attack surface. If one of the connected apps is compromised, an attacker could use it to send misleading alerts or access shared data in Slack.

Moreover, some third-party Slack apps request excessive scopes, lack regular updates, or are developed by unknown vendors. There have been cases where apps requested far more access than needed, and once authorized, they maintained indefinite access.

Security teams should apply strict vetting policies before allowing any Slack integration. Ask:

  • What scopes does this app request?
  • Who built it, and is it maintained?
  • Can we restrict it to only certain channels?

Slack’s Enterprise Grid offers app whitelisting features that can help mitigate this risk.

Data Retention, Export, and Compliance Gaps

By default, Slack stores messages and files indefinitely unless custom retention settings are applied by workspace administrators. This has implications for regulatory compliance (e.g., HIPAA, GDPR, SOX) and internal data minimization goals.

Most technical teams tend to overlook the fact that even transient-appearing messages (in threads or huddles) are still retained unless manually deleted. Message export is also available to enterprise customers from Slack, but these features are not always activated or reviewed. In the case of a breach, legacy messages can expose incident timelines, credentials, or system design information.

Make sure to:

  • Define custom retention rules by workspace or channel
  • Periodically audit exported data and logs
  • Limit long-term storage of sensitive system data in Slack
Flowchart illustrating Slack data retention options for admins.

A visual guide showing three Slack data retention paths: retaining data for a period of time, retaining data for legal purposes, and getting unlimited backup and restore.

Incident Response and Audit Limitations

When incidents occur, logs from Slack are often not detailed enough to fully trace user actions.  Unlike Git or cloud logs, Slack doesn’t provide granular logs by default for every action taken in the app.

Slack Enterprise Grid provides audit logs via its Audit Logs API, but detailed logging must be explicitly enabled and integrated with external tools for full coverage. If an attacker joins a private channel via an OAuth exploit or if a token is misused to scrape data, these events may go unnoticed without deep logging integration.

Teams should:

  • Integrate Slack logs with SIEM tools like Splunk or Datadog
  • Use Slack’s audit APIs to monitor key events (login, token usage, app installations)
  • Set alerts for high-risk actions, like new admin roles or app approvals

Slack and Shadow IT

Slack can contribute to the rise of Shadow IT. When teams use Slack to share links to unofficial tools, paste access tokens, or run scripts directly from a chat, they create unmanaged risks. Slack's low barrier to integration makes it easy for developers to run unofficial bots or use unsanctioned tools without review. Over time, this builds a parallel infrastructure of unmanaged components that are not under security policy controls. For example, an engineer might build a script that posts production errors to Slack but does so using personal tokens or insecure webhook URLs.

Data security risks escalating from secure storage to data breaches via Slack.

A simple graphic shows five steps where data can become less secure: starting with safe storage, then sharing in Slack, external leaks, unencrypted transfer, and ending in a data breach.

Organizations should:

  • Monitor for unknown bots and scripts
  • Encourage teams to follow internal approval processes for Slack apps
  • Regularly sweep messages for code snippets or sensitive configurations

What Slack is Doing, and Not Doing

Slack has improved its security in recent years, adding features like:

  • Enterprise Key Management (EKM)
  • Audit log APIs
  • Session management
  • SAML/SSO integration
  • Granular app controls on Enterprise Grid

However, many of these features are locked behind higher-tier plans. Free and standard Slack workspaces lack fine-grained access control and audit support. Slack encrypts messages in transit and at rest, but does not provide end-to-end encryption or customer-managed key options by default, except via Enterprise Key Management (EKM), which stores keys in AWS but under customer control. That means organizations need to compensate with additional monitoring and stricter internal policies to close the gap.

Insight by
Dvir Shimon Sasson
Director of Security Research at Reco

Dvir is a Professional Mountains Mover, Dynamic and experienced cybersecurity specialist capable in technical cyber activities and strategic governance.

Expert Insight:


Slack feels informal, but its backend is deeply integrated with your infrastructure. Security risks often hide not in how Slack is used, but how it’s connected.

  • OAuth Is Often the Weakest Link: Most Slack compromises stem from OAuth abuse—review every integration like you would a cloud IAM role.
  • Private Channels Are Not Truly Private: In Enterprise Grid workspaces with compliance exports enabled, admins can access private channel and DM content.
  • Rotate Developer Habits, Not Just Tokens: Teach devs to treat tokens like SSH keys. Secure handling needs to be muscle memory, not a checklist.
  • Treat Chat Logs as Source Code: Your threat model should include attackers reading years of chat logs. Don't let sensitive data live there.
  • Default Settings ≠ Safe Settings: Audit your Slack workspaces quarterly. Most security lapses are due to untouched defaults.

Conclusion

Slack is a productivity tool, but without strict oversight, it can become a weak link in your security chain. Make sure your team understands the risks and sets up controls to minimize exposure. Security hygiene in Slack must evolve as your organization grows and threat models change.

No items found.

“I’ve looked at other tools in this space and Reco is the best choice based on use cases I had and their dedication to success of our program. I always recommend Reco to my friends and associates, and would recommend it to anyone looking to get their arms around shadow IT and implement effective SaaS security.”
Mike D'Arezzo
Executive Director of Security
“We decided to invest in SaaS Security over other more traditional types of security because of the growth of SaaS that empowers our business to be able to operate the way that it does. It’s just something that can’t be ignored anymore or put off.”
Aaron Ansari
CISO
“With Reco, our posture score has gone from 55% to 67% in 30 days and more improvements to come in 7-10 days. We are having a separate internal session with our ServiceNow admin to address these posture checks.”
Jen Langford
Information Security & Compliance Analyst
“That's a huge differentiator compared to the rest of the players in the space. And because most of the time when you ask for integrations for a solution, they'll say we'll add it to our roadmap, maybe next year. Whereas Reco is very adaptable. They add new integrations quickly, including integrations we've requested.”
Kyle Kurdziolek
Head of Security

Explore More

Ready for SaaS Security
that can keep up?

Request a demo