Hi Bubblers,
As some of you probably know, one way to test your app’s API requires looking at yourapp.com/api/1.1/meta in order to see what data and workflows are exposed. We do this often to test the security of our own apps. We decided to test a number of Bubble apps and websites and found there is definitely room for improvement in this area.
All in all, most apps expose certain data types and workflows. And when you go deeper in querying those data types (search) through API, either they do not expose any sensitive fields or due to privacy rules, you cannot retrieve any items in those data types. Those apps are indeed secured, at least on their data API side.
While Bubble gives all the tools and functionality to secure this aspect, our testing also showed a large number of Bubble apps and websites that are clearly misconfigured in terms of privacy and security, resulting in thousands of records containing Personally Identifiable Information that are externally exposed and fully accessible.
While this is a critical issue for those apps, it is also compromising the Bubble community and even the platform itself. As no code is still subject to skepticism, it remains a challenge for Bubble and Bubblers to convince users and clients about the legitimacy of the platform. This data negligence undermines this effort greatly.
So in a way, the more each Bubbler ensures their own app security, the more all Bubble apps (and Bubble) will appear as solid and secure.
As our (small) contribution to that, we built a tiny Bubble app, that we use also in our own process. This app can query your data and workflow API’s and gives you an overview of what is exposed, and what is searchable. Again, following what we said before, exposing certain data should not be seen automatically as a breach. However, this small tool can help you to quickly check if you forgot something :
Regarding security and privacy good practices, the Bubble manual remains a central reference, and this chapter specifically. And you might also find a bunch of very good discussions about it on this forum (here and here for example).
While knowing about privacy and security is one thing, we think that embedding those best practices into your regular building process is key. Here are some initial principles to keep in mind:
Start Early | When you set up initially an app and the data types structure, create your privacy rules. Those rules might change in the future as you may add other functionalities and even twist a bit your concept along the development path. Anyway, having this privacy rules already there will force you to edit/change them at one point, instead of having no rules at all.
We would propose to @Bubble to check the ‘Make new data types private by default’ by default in each app. Yes, it makes building on Bubble more complicated and less attractive to non-technical new users, but it saves potential security risks in the long run.
Revert from testing | For a lot of reasons, you may want to delete temporarily a privacy rule or avoid authentication for a specific endpoint. We all do that as you need sometimes to know if your workflow doesn’t work because of privacy rules you set up before. The problem is (and we fall into that too sometimes), you easily forget to revert the security/privacy back as you’re so happy that your workflow finally went through 
Don’t mess with Users type | While all data types can contain sensitive fields and PII, the User data type contains initially ‘email’ and has a great probability to contain additional personal information. From there, you should always manipulate this data type privacy/security with caution. To refer to the previous point, privacy rules for Users MUST be set up from the start.
Happy to know your thoughts and your own tips on that