API Access Control List Guide

Sendbird allows you to restrict user actions for flexible app development. This feature enables you to assign appropriate permissions to users based on the product’s requirements.

There are four ACL options and you can configure the settings in Settings > Application > Security.

To view the image in full screen, click on the

By default, all of the four ACL options are activated. If any of the four options are inactivated, the demo apps may not function correctly. A detailed description of each setting is as follows. You need to understand each setting and enable the ACL appropriate for the business you serve.

The User List ACL (Access Control List) determines whether SDK users can access the user list API. This API returns a list of all users along with their nicknames and metadata. If your app publicly features a list of all users, it’s acceptable to have the User List ACL enabled. However, if users are not expected to view the full user list directly, this setting must be disabled. In such cases, the server will handle user list requests and return results based on user permissions through the platform API. For example, let’s say you are creating a messenger app using Sendbird. The messenger app allows an individual to chat with people who are already added to their friend list. In this case, users do not need to search for new users. Instead, the server should be configured to return only the friends of the logged-in user via the platform API. If this setting is unintentionally enabled, user lists and metadata will be exposed, possibly leading to privacy and security issues.

The User Metadata Update ACL (Access Control List) determines whether SDK users are allowed to call APIs to update their own information. This functionality enables users to modify their nickname and metadata directly. If users are permitted to change their Sendbird nickname and modify their metadata within the app, the ACL should be enabled. However, if nickname changes are restricted or require a payment, the ACL must be disabled. In such cases, the server should manage these changes by calling the relevant APIs through the platform, according to the user’s permissions. For example, if you're developing a fintech app using Sendbird, it's common to require users to display their real name. If the ACL is enabled, users could change their nickname or metadata, potentially impersonating others. If this setting is mistakenly enabled, users could bypass restrictions on nickname changes or avoid payment requirements. Additionally, allowing uncontrolled metadata changes may lead to tampering with user information.

Creating open/private channel ACLs determine whether SDK users can access the API for creating open or group channels. This API allows users to create their own channels. If the app permits users to create channels directly, enabling the ACL is acceptable. However, if your client app either restricts channel creation or requires payment, the ACL should be disabled. In such cases, the server should manage channel creation by calling the platform API, based on the user's permissions and product status. One potential risk of unintentionally enabling this setting is that users may bypass the payment requirement to create a channel.