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.

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.

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:

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

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

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:

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

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.

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

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.

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!

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.