Even if you're not working with OAuth 2.0 and user access tokens, please consider these safety suggestions when working with the Slack Platform.
As a Slack App developer, you'll be working with credentials issued to you from Slack, as well as token values representing team members, teams, and specific features of your application.
Your Client ID is one piece of information used to identify your application and frequently appears in OAuth negotiation URLs and other contexts. Your Client ID can be shared freely in code and email and cannot be used alone to act on your application's behalf.
These tokens represent specific access levels granted by the OAuth scopes you negotiated.
Bot user tokens can connect to the real time messaging API and post messages on their own behalf. They can also access a subset of API methods to better understand the channels, team members, and messages received as part of its activities.
Slack app-based incoming webhook URLs allows posting messages only to a specific channel configured by the approving team member. Their identity is always tied to the application associated with the URLs and cannot be used as arbitrary users or on unapproved channels.
Redirect URIs appear as URLs and are safe to be part of published code. However, ensure that the redirect URIs defined in a public application are limited only to domain names in your direct control.
We recommend that after you complete local development, remove
localhost and related domains from your configuration list.
Developers working with custom integrations have the benefit of each feature having its own credentials and an association with a single team. However, without the application permissions enforced by Slack apps, the tokens, URLs, and credentials used by Custom Integrations can be very powerful and require special care.
Do not share incoming webhook URLs in public code repositories. Incoming webhook URLs belong to a specific team member that installed them. When a webhook is contained within a Slack app, it is scoped to only post as a specific application-associated user and approved channel. Custom integration-based webhooks are capable of posting to any channel and have more flexibly identities.
Compromised incoming webhook URLs can be used to post unwanted, unsolicited, or malicious messages to your team.
Tokens for slash commands represent a relationship between your application and Slack. Do not store them in public code repositories.
Each application can have only one slash command token, even if they have multiple commands associated with an app. Safely store this token in your environment so that it is known only to your application and to Slack. Slack will use it to identify itself when executing slash command invocation URLs.
Bot user tokens may connect to the real time streaming APIs, and perform a number of other activities, including posting messages. Do not distribute in code repositories or yield to untrusted third parties.
The tokens generated by the OAuth Test Token Generator should never be shared or published externally. They represent all the capabilities of a specific team user.
Storing authentication secrets is difficult, and how you do it best depends on context, usage, and design requirements. While it would be super cool if all tokens were encrypted with individual keys controlled by the customers, most implementations do not allow that. Here are some things to consider when storing tokens to ensure that we're doing everything we can to prevent accidental exposure or mix-up of usage.
The 7-Layer OSI model breaks out how applications and computers function over a network and can provide a useful model for thinking about security at each layer. By breaking apart each layer, it's possible to look at different risks and mitigations to best apply.
The Application layer is mostly focused on high-level APIs, and how your application exposes itself to an end user. Here are some things to consider:
These layers encompass most of the non-application-based internet-plumbing, including protocols such as TCP, IPv4, MAC, and Ethernet. We're going to assume for safe token usage and storage that these layers are already secured, however there are a few points to consider, especially if you are hosting in the cloud.