At QuickBlox, we understand that our customers value transparency and accountability when it comes to the security of their data. To prove our ongoing commitment to providing customers with the highest level of data protection, we also recently became SOC 2 certified following a rigorous audit of our controls and processes.
That’s why we wanted to address the recent article from Check Point Research (CPR), in collaboration with Claroty Team82, about their research project investigating QuickBlox platform’s security.
These two cybersecurity research companies contacted us about some vulnerabilities found on our platform. Once our team of developers had already addressed these vulnerabilities, they released an article about the investigation and thanked us for addressing the flaws with security improvements.
What Were the Vulnerabilities?
QuickBlox APIs were created to simplify the onboarding of real-time chat and video services for customers. It helps companies enter the market faster with APIs and SDKs that shortcut product and engineering delivery and allow straightforward integration and testing.
The vulnerabilities found were not bugs but structural issues with the API design, something we couldn’t immediately fix without breaking the user experience.
Originally our APIs were designed with a mobile-first approach, where they provided the necessary functionality without needing servers or backend support. App development was simplified, and mobile developers could directly tie their apps to QuickBlox. However, if the application credentials were not stored safely by encrypting or obfuscating them in the client apps, that opened a security issue: the possibility of accessing the app’s credentials by decompiling or reverse-engineering the app.
There was also a security bug in the platform, where our API allowed fetching of users’ list with the application session token (which should be restricted because this token is only used to register/create a user). We immediately fixed that as soon as it was discovered.
Creating Flexible Software for Ease-of-Use
Now you might be wondering: If we were aware of the potential risk in storing application credentials on the client side application, why did we allow this approach?
The answer is we wanted to enable developers to build quickly and with ease. And there are many circumstances when storing credentials on the client side is far less problematic: Sometimes all a developer wants to do is analyze a platform to see if it fits their needs by quickly building a Proof of Concept or Minimum Viable Product. In these cases, when there are no real users or data, fast integration is key and there is less concern about security.
It’s important to note that we’ve always had secure and recommended ways of managing credentials and authentication, which are detailed in our official documentation. These include:
- Custom Identity Provider (CIdP): This allows you to delegate authentication to an external service. In this case, user credentials and password management are handled by an Identity Provider (IdP):
- Creating a session on the server and initiating SDKs with the ready session token:
While the vast majority of our customers use these recommended methods,
a small handful of customers chose to implement the other method in production. They have all been contacted to update their application according to best practices.
What We Did to Enhance the Security
As soon as CPR contacted us, we immediately drafted an execution plan and quickly fixed our APIs.
Here are some additional measures we took:
- Updated documentation to add security notes to critical places like Setup and Authentication.
- Fixed the bug with the Application Session Permissions. Now, the application session token can only be used for user registration/creation.
- Created API keys feature and added more endpoints, which enhances the possibility of managing users and their sessions on the customer’s server.
- Updated SDKs to simplify the initialization of the SDK and start the SDK with the session token. This avoids the need to store application credentials on the client’s end.
- Added the session privacy permission settings on the admin dashboard, allowing the app admin to configure the permissions of the application session token and user session token. This means developers can disable the user creation with the application session token and restrict the data fields in the user collection.
Summing Up
The QuickBlox team takes security very seriously, and we consistently review and improve our platform, documentation, and internal processes. While we’ve always had and recommended secure practices for using our SDKs in a production environment, we’ve added even better and more convenient ways to do so with our new features and documentation.
For detailed technical guidance on security best practices when leveraging QuickBlox’s real-time chat and video calling SDK, see our recent blog Securing Your Communications.
