Security: How to avoid Database Leaks on your Bubble app?

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. :point_down:

Product Update (8)

(this article is also available on Flusk’s blog)

:one: What is a database leak?


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 - User
  • Invoiced Company - Company
  • Amount - number
  • Fee - number
  • Invoice PDF - file
  • Paid? - boolean (yes/no)
  • Used Credit Card - Credit Card

And the Credit Card Data Type would be represented with the following structure:

  • Credit Card Digits - text
  • Expiration Date - text
  • CVV - text
  • Owner - 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.

:warning: 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.

:rotating_light: Because on Bubble, Privacy Rules are the only thing that really protect your data.

:two: 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.

:three: 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).

:four: 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, the Freelancer and the Invoiced Company fields 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

:closed_lock_with_key: Automated Security Audits for apps
:chart_with_upwards_trend: Advanced Logs Monitoring and Error Handling for apps
:bird: Twitter/X Account with many security tips

With :heart:

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!


Its a big topic, what i suggest read about privacy rules in bubble. Google about it and use bubble manual.

Don’t know why I never considered this, great suggestion

Amazing post, @weswas. It always takes me a while to figure it out if everything is set up correctly, now the problem is over hahaha

Btw, I just tested it and it showed me a few privacy problems in a project I’m working on. Thanks for the contribution bro!

1 Like

Definitely, but we thought it would be a nice addition to the Bubble manual (hopefully?)

Yes! The only thing is that it can take some time to build and maintain, and preferably you want to remove this page before every push to make sure not to build an easy way for people to scrap your website :melting_face:
Feel free to share if you’ve been using another method btw!

Thank you! The Privacy Rules Checker always surprises people :laughing: Glad you’re safe now!


Recently the privacy rules checker detected a data leak for my app for just one user’s first name and email address, not an entire data type or field. Can you help me understand why this is happening? I’m confused as to why only 2 fields of one user are impacted.

Love what you’re doing at Flusk!

What are your privacy rules?

I bet you have something like ‘This User’s Organisation is Current User’s Organisation’ and the leaking user’s Organisation field is empty, which would mean that This User’s Organisation (empty) is Current User’s Organisation (empty when logged out)

1 Like

You’re right! :smile: 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?

User’s own team
This user’s team is Current User’s team

Users own data
This user is current user

Everyone Else
All fields are unchecked. Find this in searches, view attached files, allow autobinding - all unchecked.

Edit: I have no publicly viewable data types. What’s the best “fallback” privacy rule that would hide all data types from any not logged-in user?

This is actually an edgecase which you have to account for.

If the user’s team is empty, the ‘User’s own team’ rule breaks down. This is because an unauthenticated user’s team (no team) is the user’s team (no team), so that privacy rule actually outputs a true.

Check out @georgecollier 's recent post about it.

Oh also, it’s not really an edge case. 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.

Privacy rules are additive. All users start by having access to nothing.

Suppose Privacy Rule 1: (PR1):

PR1: Can view field Y

PR2: Can view field Z

If the User meets the condition for PR2, they can see Z. If they meet PR1, they can see Y. If they meet both, they see Y AND Z (there’s no hierarchy/priority). Privacy rules grant permissions when fulfilled, never take away.

Another reason to not go around deleting things.
Gotta use cascading deletion, or a ‘deleted?’ field.

But i definitely agree that it can happen, and I’m glad that you pointed it out and suggested how to patch it up :slight_smile:

That’s a very good point. We see that all the time and it’s the number 1 reason why people get confused about their Privacy Rules Checker test. Because they see the data leaking altough their Privacy Rules seem well defined.

I’ll ask @weswas to add it within the post, maybe at the end in a “Extra tips” section?

1 Like

I just updated the post to include an “Extra Tips” section referencing @georgecollier’s super useful advice.
Thanks George!

1 Like