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.
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.
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:
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.
As soon as CPR contacted us, we immediately drafted an execution plan and quickly fixed our APIs.
Here are some additional measures we took:
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.