Keeping credentials secure is important whether you're developing open source libraries and tools, internal integrations for your workspace, or Slack apps for distribution to workspaces across the world.

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.

• Security considerations for Slack apps
  • Restricting token use by IP address
  • Verifying requesting from slack
  • Rotating and expiring tokens
• Safe token storage
• 7-layer OSI model

Practical considerations

Security considerations for Slack apps

As a Slack App developer, you'll be working with credentials issued to you from Slack, as well as token values representing members, workspaces, and specific features of your application.

Client ID and secret

1. 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.

2. Your Client Secret should be treated delicately. It is how you securely identify your application's rights and identity when exchanging tokens with Slack. Do not distribute client secrets in email, distributed native applications, client-side javascript, or public code repositories.

Slack-app based user & bot user tokens

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, members, and messages received as part of its activities.

User tokens, such as those received through the Add to Slack and Sign in with Slack flows are capable only of the permissions granted to it during the OAuth flow using scopes.

Store user and bot user tokens with care and never place them in a public code repository or client-side code like Javascript.

Restricting token use by IP address

One way to build confidence in the sanctity of your user and bot tokens is to lock down their usage to a known set of IP addresses you control: IP whitelisting.

IP whitelisting is only available if you're building an internal integration and have explicitly marked your app as undistributed.

By providing a whitelist of IP addresses, Slack will only accept requests to Web API methods if originating from a listed IP address. If the request matches your whitelist, Slack will execute the request and respond as usual.

If the request originates from an IP address not listed in your whitelist, it will be rejected with this response:

{
  "ok": false,
  "error": "invalid_auth"
}

IP whitelisting only applies to token use against the Web API for internal integrations.

Configuring your whitelist

Navigate to your application management and select the OAuth & Permissions pane. The Restrict API Token Usage section allows you to specify a whitelist of acceptable public IP addresses.

Up to ten entries are allowed. Each entry specifies either a CIDR range of IP addresses or a single IP address.

For example:

• Entering 101.101.101.106 will whitelist only that IP address, which we'll consider as 101.101.101.106/32.
• Presenting a submask like 101.101.101.0/24 will whitelist all 256 IP address between 101.101.101.0 and 101.101.101.255.

"Local" IP addresses cannot be whitelisted and IPv6 is not supported.

Verifying requests from Slack

Slack also supports several ways to verify the authenticity of its requests to your app. Read more in the verifying requests from Slack documentation.

Rotating and expiring tokens

Traditional Slack apps can't use token rotation yet.

Legacy workspace apps that were part of our developer previous could use short-lived tokens and regularly refresh them with OAuth 2.0. Learn more.

Eventually, all apps will be able to use token rotation.

---

Incoming webhook URLs

Slack app-based incoming webhook URLs allows posting messages only to a specific channel configured by the approving 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

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.

Safe Token Storage

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 actual token

• Do you need a token to make your functionality work?
  • If not, err on the side of not storing more customer secrets than you need to.
• Are you asking for a least-privilege token?
  • Most application need only perform a handful of things with a token. Make sure you are requesting the most limited token authorization scopes possible to protect your customers in case of a breach.

Thinking of things in the 7-Layer OSI model

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.

7/6. Application layer and Presentation layer

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:

• Don't expose the token to the end user once it is stored in a database
  • Ensure there is no functionality that echoes back tokens (or any other customer secrets) to the user. Check your error scenarios especially. Unless this is absolutely required, consider creating a middleware layer to facilitate the usage of a stored token without storing it within your application code.
• Lock down the usage of your application itself to prevent misuse of the token
  • Think about OWASP Top 10 Web Vulnerabilities such as XSS, CSRF, SQLi
  • Can an attacker abuse your application's functionality to gain access to a token? or trigger functionality that may be undesirable functionality?
• Think about rate-limiting
  • Does your application utilize rate-limiting in a way that prevents misuse of a token? Spamming a token can potentially disable that token, leaving your integration in an erroneous state.
• Use a database to store tokens, and do not hard-code any tokens into code
• Don't consume tokens via the query string of a URL via a GET request. Always use a POST request when transmitting secrets over HTTP

5. Session layer

• Store tokens in a way that directly links them to the owner (workspace and user)
• Ensure that if a user deletes their account, data, or integration, that you also delete that token from your production systems, and backups
• If you no longer have need for a customer's token, delete it immediately from all production systems and backups
• Make sure that there is absolutely no way to expose one users token (or the functionality of that token) to another user on accident
• Ensure that your sessions on your application utilize best practices on session id generation, and test for the ability of one session to know about our see the contents of another user's session. (ensure that any debug functionality for user impersonation among other things does not exist in your application)

4. Transport

• Ensure you are using proper TLS to encrypt all traffic between you and the customer; you and the service you're using the token with to ensure the token never gets transmitted unencrypted across the wire
  • Make sure you do not have any "Ignore SSL/TLS Errors" in your application code
  • If you have a web-facing service, ensure that you do not have any mixed content, and that your certificate setup is proper and supports modern cryptographic standards.
    • You can use Qualys' SSL Labs to help test for this
• Once your application has knowledge of a user token, ensure that you are not logging it, or moving it in any way outside of your application's database

3-1. Network, Data Link, Physical

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.

• If you are using a cloud provider (AWS, DigitalOcean, Heroku, etc), make sure that your account has two-factor authentication enabled, and that you are using strong passwords
  • Make sure that the only accounts with access to your production systems actually need that access
• If you are backing up your data, ensure that you are storing it in a safe location that is locked down. Unsecured backups are easy targets for attackers to practically steal most if not all of your application's data and secrets
• If your application is not web based, but based on a computer or mobile device, ensure that you are using that platform's guided advice on how to store secrets. You should never have an instance in which you are writing a token to disk in plaintext when there is a system keychain or other encryption mechanism available.