Hi all,
Wesley from Flusk here.
As of today, a lot of Bubble apps have database leaks.
In this thread, I’ll try to give you some tips to avoid that. 
(this article is also available on Flusk’s blog)
What is a database leak?
Context
All of you probably know what a database leak is but let’s bring all of you to the same stage.
To illustrate a database leak, we could take the example of a Bubble app with the following functionalities:
- Freelancers use the app to create invoices for their customers
- Companies log in to the app to see and pay the invoices
- The admin team can see how many invoices are created and their total revenue, as their pricing model is based on a % of the invoice. Let’s say they charge 0,5% of what the freelances are charging.
Now, let’s say that an invoice is represented on the database side by a Data Type with the following structure:
Freelancer- UserInvoiced Company- CompanyAmount- numberFee- numberInvoice PDF- filePaid?- boolean (yes/no)Used Credit Card- Credit Card
And the Credit Card Data Type would be represented with the following structure:
Credit Card Digits- textExpiration Date- textCVV- textOwner- text
Obviously, no app built on Bubble would ever store credit card numbers in plain-text. That’s just an example.
Data Leak
Now, let’s say that no Privacy Rules are defined for both the Invoice and the Credit Card Data Types.
Even if at first sight no one would notice anything, in reality the developers made a big security mistake here.
But this means that anyone could consult and access the following data:
- How much money do a given freelance make?
- How much money a given company spends in X field (at least)?
- What is a given company working on at the moment?
- How much fees has the platform taken in total?
- What are the credit card details of the card used by a given company?
- And so on.
Because on Bubble, Privacy Rules are the only thing that really protect your data.
What are the risks of a database leak?
A database leak can represent many risks.
Here is a non-exhaustive list:
- Data Protection and Privacy Law Violations : Many countries have strict data protection and privacy laws (e.g., GDPR in the European Union, CCPA in California, USA) that require businesses to protect personal data. A leak could constitute a breach of these laws, leading to hefty fines and penalties.
- Regulatory Investigations and Sanctions
- Litigation from Affected Parties
- Reputational Damage
- Loss of Trust from Potential Investors
And the list goes infinite.
Trust me: you don’t any data to leak from your app.
How to know if I have a database leak?
1. Using a Privacy testing page
With Bubble’s native Privacy Rules builder, it’s actually pretty hard to be sure no data is leaking from your app. There is unfortunately no way to check in a glance if some data are leaking on your app.
The easiest solution is to build a page that will serves us as a Privacy Rules tester.
First, create a blank page on your app, then for each database in your app, we want to create a table element with as columns all your datatype’s fields.
Do you remember our Invoice database from the example above? Here’s what it would look like.
Then, in the Data Source of your Table Element, you want to perform a Do a Search on all Invoices in your database.
Finally, you can open the page in your browser and see if data is leaking. If the cell remains empty, then the field is properly secured, otherwise it means your Privacy Rule is not defined properly.
Keep in mind that Privacy Rules depend on your user role, so you might want to give it a try with different user roles and also as a logged out user.
2. Using Flusk Privacy Rules Checker
The above solution is effective but also definitely time-consuming.
But this was until we introduced our Free Privacy Rules Checker.
Basically, we’re querying every single database on your app and show you the data we have access to as a visitor.
And we’re planning to go even further:
In the Flusk app, you’ll soon be able to check for data leaks with a given User Role.
Said the other way, read this sentence:
With Bubble’s native Privacy Rules builder, you can define a role and allow them to see some specific fields of your database.
At Flusk, we twisted it to allow you doing this:
You are now able to see which data is visible for a given role.
You could compare this to passing an exam by having a sheet next to you with the right answers the teacher is waiting for.
No need to wait for the teacher (aka the hacker) to correct your exam (steal your data).
How can I fix a database leak?
To fix a database leak, you should define Privacy Rules for the following Data Types:
* User
* Credit Card
* Invoice
Credit Card Data Type
Let’s start with the Credit Card Data Type. If we resume it in a sentence, we could say that no one should be able to access it unless the Owner of the Credit Card.
This should be pretty easy.
We just need to create a new Privacy Rule allowing to view fields if the Creator of this Credit Card is the the Current User.
For Users who do not match this rule, they shouldn’t have any rights.
In Bubble’s language, this is how you’d write the rule:
Current User is This Credit Card's Owner
Invoice Data Type
For this Data Type, it will be a bit more complicated.
We have 3 use-cases where Users don’t have no rights at all on this Data Type:
- When the User is an Admin (he needs to consult at least the
Fee, theFreelancerand theInvoiced Companyfields to calculate the amount charged to the freelancer) - When the User is part of the Invoiced Company
- When the User is the Freelancer that created the Invoice
If a User don’t match any of these rules, he’ll have no rights at all on this Data Type.
Now, let’s handle these 3 cases:
Checking if the User is an Admin:
Depending on how you built your Role system on your app, you might have something slightly different. But that’s how it looks on my demo app:
Current User's Role is Admin
Let’s allow him to see the 3 mentioned fields.
Checking if the User is the Freelancer who created the Invoice:
This one is quite straightforward:
Current Users is This Invoice's Creator
It’s his own Invoices, so let’s allow him to see all the fields.
Checking if the User of part of the Invoiced Company:
This one’s also pretty easy, but we’ll have to check if the User is inside the list of Members listed in the Company.
This Invoice's Invoiced Company's Users contains Current User
Let’s allow him to see all fields as well, except the Fee one:
Extra Tips
You absolutely need to take care about deleted data that will make certain privacy rules valid.
It can happen really easily if you delete the attached data (e.g suppose data is linked to an Organisation).
If you are deleting an Organisation, and you forget to delete a certain data type or the user itself, that makes the Organisation field empty and effectively makes the data public.
Thanks @georgecollier for that contribution!
I think this is it, Bubble friends.
If you have any questions about Privacy Rules, Data Leaks, or if’d like me to handle another security topic, I’d love to see your reply in this thread.
Wesley Wasielewski
CEO & Co-founder at Flusk
Automated Security Audits for Bubble.io apps
Advanced Logs Monitoring and Error Handling for Bubble.io apps
Twitter/X Account with many Bubble.io security tips
With 
Bubble is a very safe platform in itself.
Most security issues come from people who develop apps using Bubble and:
- Don’t follow security guidelines
- Don’t have the necessary resources and tools to check their security
Let’s keep trying our best!
Glad you’re safe now!
It’s interesting… you’re right about the one user… for some reason they are not on a Team. However, wouldn’t the Everyone Else rule override that by covering all other use cases?