Api key security issues


How do i prevent someone from stealing my appId and connecting their users to my app? and why does Sendbird have this open/not-so-secure policy deployed by default?

For example, i used the appId and channel from your live chat example, and could connect my codesandbox client to it. can i build my entire application from that appId? could someone else build their entire application from my appId as well?

Thank you,

Hi @foobar

This is a great question. The application ID in our Sample App, allows users to connect without a Session/Access Token. This is why you can easily swap out the Application ID in your example application. Because the Sendbird SDK requires you to make a connection after initializing an instance of Sendbird, you would ideally want to alter your security settings in the dashboard to require a Session/Access Token which would need to be generated via the Platform API which in turn requires an API Token.

Additionally, you can set allowed domains and IPs to further restrict access to these items.

Let me know if you have any additional questions.

Hello @Tyler ,

Thanks for providing informations about securing my own app. Additionally i had questions about this particular sample app, and security in general regarding sendbird.

  1. What are the restrictions in this sample app ? Could it be possible for some people to use this sample app to build their service (instead of subscribing to Sendbird normally)?

  2. Why does Sendbird have this open/not-so-secure policy deployed by default (rather than secure by default, and not secure on demand)?

Thanks for your responses,


The application ID’s used for our sample applications are monitored and it would be very apparent if someone where to attempt to use it to build an application. Additionally, should we notice it being abused it would be easy to revoke the application ID preventing anyone from using it going forward.

As to your second question, I can’t speak to the specific reasoning, as I’m not involved in those decisions. My thought would be its designed in a way to get people up and running with the SDK as soon as possible. Most applications start out as trials and thus we want users to be able to implement the API without much trouble. As you progress with setting up your application, then it makes sense to then begin ensuring the application is secure. In most instances, you do this in multiple parts. One of those parts could be implementing authentication in your application, and another part would be ensuring that you’re generating access/session tokens via the platform API and denying login to any application that is accompanied by that token.

Let me know if you have any additional questions.