Privacy Rules in Bubble.io: What you need to know

Privacy Rules are the most secure way to keep data private in Bubble. Ironically, it’s also one of the most overlooked.

Bubble have seen the same thing apparently, and have introduced several changes to nudge developers towards keeping data both when data types are created and when they’re viewed in the editor.

Bubble editor showing the default privacy rule setting checkbox
Bubble introduced warnings in clear language to nudge developers to use Privacy Rules.
Looking at Data Types in the Data Type also gives you a head up when they’re exposed.

What does this tell us? Well, that Privacy Rules are important – you need to learn how to set them up properly and shouldn’t even consider every releasing an app without them.

(Click this link If you want to skip directly to the Privacy Rules FAQ)

What are privacy rules for?

Privacy rules are settings that you apply to specific Data Types in your database to restrict who has access to it. A typical use case (but by no means the only one) is for Users to only be able to see things that they themself have created. If you create a document in Google Drive or a note in Evernote for example, you’ll naturally assume that not every other user of those products have access to your data. If they were Bubble apps, privacy rules would be essential to keep that data private.

Screenshot of the create document menu in Google Drive.
Using cloud-based software like Google Drive, we take it for granted that our documents are private and secure. Your users expect the same from your app if you make that promise.

Privacy Rules are applied to all data server-side, meaning that the protected data never leaves Bubble’s servers. They’re also applied across your entire app, ruling out the possibility of data breaches because of human error. You may set up a search with a specific constraint to protect the data, but that constraint only applies locally to that specific search.

It’s important to realize that all data that Bubble downloads as the result of a search is available for anyone who wants to see it, even if you’re showing it on the screen. Simply open up the DevTools, find the relevant search in the network list and click on it – you’ll be able to see all the data on every record, even if you’re not referencing the data anywhere.

Let’s have a look at an example. First, let’s check the Privacy Rule set on our User data type:

Privacy Rules fully exposing all data set in the Bubble editor
With the View all fields and Find this in searches checked, we’re telling Bubble that all users (including non-logged in users) can see all fields on all other users.

Then we’ll load some data into a Repeating Group without using that data for anything else.

Setting up a search in Bubble that downloads all Users to the browser.
In the example above, we’re downloading a list of all Users into a Repeating Group. No details are shown on the screen, as the Repeating Group doesn’t contain any elements.

Now many would assume this is safe. After all, we’re not exposing any data on the screen, and the only thing we can do with the Repeating Group is counting the number of cells to see how many users there are. But what’s going on in the background?

You’ve given Bubble a simple command here: download all Users. That’s it. What does that mean? Well, unless your Privacy Rules say otherwise, you’ve downloaded all data on all Users into the browser. Let’s have a look at it in Chrome Developer Tools

Screenshot of exposed user data in Chrome Developer Tools.
Each entry in the network tab let’s us see all data involved in the process: in the case of this search, that involves exposing personal data.

As you can see, you don’t need to be much of a hacker to see a nice, ordered list of every user in the system, complete with personal info like email and date of birth. All this from a blank page!

Now, let’s have another look at how a small change in Privacy Rules changes this. We’ll still make the search available to all Users, but we tell Bubble that the Date of birth and Email are off limits:

Disallowing the date of birth and email to be exposed using Privacy Rules.
Unchecking the View all fields box let’s you select which fields to see. Note that we’re still working on default permissions.
Checking that the email and date of birth is hidden.
By using Privacy Rules, we’ve hidden two private fields on the User, making the app more secure. Note that we’re not even exposing that there is a field called date of birth anymore.

The most important points to take to heart here is that:

  • Bubble can download a lot more data than you think
  • That data is stored in your browsers memory unencrypted
  • Revealing that data in the DevTools doesn’t require a professional hacker – it’s a trivial task that takes less than 30 seconds

How widespread is this problem? For new Bubble developers, it should be a high priority to learn – but the fact that I see agency-built apps with live users expose everything from user data to Stripe secret keys in the Developer Tools is worrying to say the least. As professional developers, we all have a responsibility both to clients and to maintain Bubble’s reputation as a secure platform.

Bubble have held up their end of the deal by providing the tools – so let’s use them.

The Privacy Rule tab in Bubble

The basic editor structure

The basic structure of Privacy Rules consists of two questions:

  1. How should this data be made available to see and edit for Users matching specific criteria?
  2. How should this data be made available to see and edit for everyone else
Screenshot of the two steps needed to set up Privacy Rules.

Note here the words be made available to see and edit: the easiest way to think of Privacy Rules is that they don’t restrict access – they grant it. In other words, you are setting up your Rules in order to allow your users to see and edit data under specific conditions.

A simple rule to keep in mind to avoid conflicting rules is that checked boxes override unchecked ones. A checked box grants access to anyone matching the criteria, but an unchecked one doesn’t ungrant it. If that same box is checked on any other rule that matches the current User, then that User will have access.

Setting up a Privacy Rule

After clicking the Define new Rule button, we’ll get to work on the different sections of the rule in the order they’re listed on the screen. You’ll notice that adding the first rule also creates the second one (everyone else) automatically.

Name

The name of the Privacy Rule is just for your own reference – give it any name you want.

When

This is where you set the condition for the rule. Conditions are built using Bubble’s expression editor just like everywhere else, but you’ll notice that you can only access two data points: the Thing you are adding the Privacy Rule to, and the Current User.

Setting the constraint on a Privacy Rule.
When setting up Privacy Rule conditions, you only have access to the Thing in question and the Current User.

Rather than thinking about the condition on the full list of Things you are protecting (all users), think of it as a rule that’s applied to one User at a time. That way, Bubble’s choice of words make perfect sense. Let’s set up a rule that specifies that This User is the same as the currently logged in User. Take a look at the highlighted image below, and how the editor is set up to be read as an easily understandable English sentence:

When This user is Current user, Users who match this rule can view all fields. It may not be Shakespeare, but Bubble’s focus on humanly readable expressions make the privacy rules easy to understand.

View all fields

This checkbox, as we explored earlier, determines whether all fields (name, email, etc) on this User should be visible to Users who match our When criteria. If you uncheck this box, you can select which fields are visible.

Find this in searches

This checkbox being checked tells Bubble that whenever a Do a search for is performed, records that match the criteria will be included in the result. Note that unchecking this box doesn’t hide the record in every other circumstance: as the name suggests it only applies to searches. If you reference the record in some other way, it will still load.

View attached file

Let’s spend a little bit of time on this point, because it’s easy to misunderstand. Many assume that if you set up a field on a User that contains an uploaded file, that file will be protected by the View attached file setting. This is not the case.

This setting protects files that have been deliberately set to private when it was uploaded with one of Bubble’s uploading plugins. It does not protect files that didn’t have that box checked or were uploaded directly in the Bubble editor. For this setting to work, you need to adjust some settings on the upload element. In the case below, we’re using a PictureUploader element

The View attached files rule only works if you’ve specifically set the file to private when it was upladed – a common misunderstanding.

Keep in mind that this setting protects the file – not the saved URL. The URL of the file can still be exposed in DevTools, and potentially expose information that your users don’t want it to. If you want to hide this information, you should also uncheck this field by unchecking the View all fields and the field in question.

If anyone with the URL tries to view the uploaded file, they’ll see this error messag:

Allow auto-binding

This box determines whether Bubble allows for a field to be saved using the Auto-binding feature. The rule is fairly self-explanatory, but it’s still important to read exactly what it’s saying: it specifically allows or disallows auto-binding, not writing to the Thing in general. This setting is one of the reasons we consider auto-binding as the best practice way to save data: just like exposing data unintentionally in searches is avoided app-wide by unchecking private fields, disallowing auto-binding makes you completely sure that no one can edit a specific field without the right credentials.

Checking the box let’s you pick which fields you want Users to be able to edit. If you check a field to allow auto-binding, but uncheck it in the View fields settings, the User will be able to edit that field, but not see it. In fact, any input field that is auto-bound will accept the edit and then immediately hide the content after it’s saved.

Everyone else

When you set up a Privacy Rule, always go over the Everyone Else section to verify that you don’t have any conflicting rules. Keep in mind that a checked box overrides an unchecked one: any box you have unchecked with a specific condition in the rule above has no effect is that same box is checked under the Everyone else section.

Privacy Rules and workflows

Now you might ask: how are workflows affected by our new Privacy Rules? In general, they aren’t. Any change that you make to a Thing in a workflow, even if the Current User doesn’t have access to that field, will still be made.

Any change that you make to a Thing in a workflow will still be made, even if that field is not viewable by the Current User.

Workflows are still affected in some ways, as they are run with the current logged in User’s credentials. Again, keep an eye on the language that Bubble uses in the Privacy Rule section: it’s saying that a User can’t see a field – it doesn’t say anywhere that he can’t make changes to it (outside of auto-binding). In other words, if a workflow tries to see a field or search for a Thing the Current User doesn’t have access to, the result will turn up empty, which might affect the workflow.

Security during submitting data via a workflow

Let’s say on page load that you’d like to Create a new Thing that is invisible to the current User by use of Privacy Rules. You may for example be logging a timestamp for when the user visits the page. Remember that Privacy Rules protect database records – not Workflows. The workflow will run on the client-side page, and any data along with it will be available on the User’s device if they know where to look for it.

In most cases this is not a problem – but if that information is somehow sensitive (like a workflow generating a pin code or a password), then using an on-page workflow is not secure.

Privacy Rules FAQ

This section quickly answers some of the most-asked questions we get about Privacy Rules. If you’d like to add questions to this, let us know in the comments at the bottom of the page!

What are Privacy Rules?

Privacy Rules are restrictions that you can apply to your Bubble data to control who has access to it. It keeps database records out of search results, restricts which Users can see and edit all or specific fields and file attachments.

As an example, you could use Privacy Rules to let Admin Users in your app have access to specific data that Regular Users don’t.

How do Privacy Rules work?

Privacy Rules are applied on the server whenever you request information, like using the Do a Search for command. Technically, Privacy Rules are like any other normal constraints that you place on a search, but applied across your entire app.

Do Privacy Rules apply to Lists saved on a Thing?

Yes and no. You can restrict access to the Field that contains that List, and stop the list from loading that way.

But if you have restricted access to a Data Type by unchecking the Find this in searches, any records in a List will still show up, as a list is not the same as a search.

Are Privacy Rules secure?

Yes, if set up correctly they are the safest way to make sure private data stays private.

How are Privacy Rules added to a Data Type?

You add new Privacy Rules by opening the Data tab and the Privacy Rules section. To understand how Privacy Rules work, it helps to think of them as allowing access rather than restricting it. Every rule you add gives access to your data in a specific scenario.

Why are Privacy Rules needed?

There are many reasons why constraints are not enough to keep your app’s data secure. The most obvious one is simply human error: if constraints are not applied across your entire app, then a single mistake somewhere in the app can open up for a severe security breach.

What does “allow auto-binding” in Privacy Rules mean?

Auto-binding allows you to set up Bubble to auto-save data in input fields as the User types. For example, the User could save a first and last name to their profile in a form without having to click a Save button.

If this box is unchecked on conditions that match a specific User, they’ll simply see an error message if the try to save anything. Using auto-binding in combination with Privacy Rules is the safest way to control who can make changes to database records.

Do “Make changes to a Thing” workflows override allow auto-binding?

Yes, if you use the Make changes to a Thing action to edit something in the database, that change will be made regardless of the auto-binding rule.

Are Privacy Rules better for app performance than regular conditions?

No, there’s no difference in performance between using regular conditions and Privacy Rules. You can sometimes use Privacy Rules creatively to get a performance advantage in certain scenarios but generally they’re better thought of as a security feature, not performance.

What does “Make this data type private by default” mean?

Checking this box means that Bubble will automatically apply a basic privacy rule to the new Data Type you are creating. The rule is that records will only be accessible to the User who created them.

Do Privacy Rules work with Back-end Triggers?

Back-end Triggers run independently of Privacy Rules.

That concludes our guide to Privacy Rules. If you feel there’s something we haven’t covered or you have questions about this guide, let us know in the comments below.

Share:

More Posts

Understanding Bubble Groups

Bubble has five different group types. While they’re all used as containers, their use differs greatly. This article explains the difference between them in detail.

Bubble’s new expressions: SPLIT BY and ARBITRARY TEXT explained

Bubble quietly launched two new features in July 2021 that are quite useful: split by and arbitrary text. They’re both expressions that solve tiny problems that otherwise would require cumbersome workarounds, and are absolutely worth checking out. You’re not gonna

Combining icons and text in Bubble

Placing icons inside of your text elements by using BBCode is a quick way to reduce the total number of elements on your page and make sure your app runs smoothly. Read on for how to do it.

2 Comments


Lindsay
June 24, 2021 at 09:27
Reply

Nice clear article … better than Bubble’s own documentation. One question with this ….

” The workflow will run on the client-side page, and any data along with it will be available on the User’s device …. ”

Are workflows really run on the Client? Or just the “on page load” workflow?


    Petter Amlie
    June 24, 2021 at 14:17
    Reply

    Hi Lindsay,

    Thanks for reading and commenting! To clarify that sentence, the full workflow runs of course on the server, but it starts in the browser. So the browser sends a command to the Bubble server (it doesn’t matter what triggered it). So that process looks like this:

    Send action (client-side, not encrypted and visible in browser) -> Transit (travel through the internet to reach the server, encrypted) -> Server completes the command (encrypted)

    So again, the only unsecure part is on your own device. But I’m bringing it up as you should be aware that at some point in that process, the information rests unencrypted in your browser. In most cases, the User already knows the info (like updating the name of your own User), but in niche scenarios, this is worth knowing about.

Leave A Reply

Your email address will not be published. Required fields are marked *

*