Protecting data with privacy rules

This section covers how to use privacy rules to protect private data

This section takes a long-form look at what privacy rules are. To see the more concise and technical documentation you can check out our core reference entry.

Privacy rules are an essential part of your app's security. Any database data that is private or sensitive needs to be protected with Privacy Rules to be considered secure.

Always stay on top of your app's Privacy rules to let your users safely entrust their data to your app.

Privacy rules are conditions that you set up on each data type in order to protect the data from being viewed and edited by unauthorized users.

What are Privacy rules?

All the data that you store in the database is hosted on a server. Privacy rules are rules that instruct the server to only send data to the browser or write to the database if certain conditions are met.

For example, we could allow our Products to only be viewable by people who are logged in. The Privacy Rule in humanly readable terms would be:

Only return the data if the current user is logged in

The logic in this case would be that we ask the server for some information by using a data source such as Do a search for and an operator like Name to show a Product name. If the privacy rule above is active, Bubble will only return the data if the query came from a user that is logged in.

The reason this is so essential to app security is that it's stopped on the server-side, and the data remains in an encrypted state in the database instead of being sent to the browser where it could be viewed.

As illustrated above, the privacy rules make up a sort of firewall for your data – every request to the database goes through a process of before it's completed or rejected.

Client-side data

Before we explore privacy rules, it's important to understand that all data that reaches your user's device is by definition no longer secure. As a developer, you need to be aware that the as long as the data has been downloaded to the user's device – even if it's not displayed anywhere in your app – the user of that device can access it by looking at the data traffic being sent to and from the Bubble server.

This is fairly technical subject – suffice it to say that the only way data remains truly inaccessible is ensure it is not sent from the server in the first place. And privacy rules are the way to do that.

It's also important to stress that in most cases, we want the data to reach the device. If not, we wouldn't be able to work with data at all. The important task is to ensure that only the intended information is sent and no unauthorized data.

In an eCommerce store we would likely find data in the database that has different security requirements:

All Products should be viewable by anyone (if not, no one will be able to buy anything)
All Shopping carts should only be viewable by the user who created it (to keep the user's purchase history private)

The Products are known as public data and the Shopping cart is private data.

How privacy rules work

Using the Bubble API introduces some new settings in the Privacy Rule tab. You can read more about those special settings in the article below.

Article: Data API Privacy Rules

Article: Workflow API Privacy Rules

Bubble features a privacy rule editor that lets you control the privacy settings on all your data types in one central place. You access this by going to the Data tab and then clicking Privacy.

Privacy rules protect your data types in the following ways:

You can stop specific fields from being viewed
You can stop the data type from being found with Do a search for
You can stop users from viewing uploaded files
You can stop users from making changes with auto-binding

Caution: Privacy rules do not update automatically on the page if the privacy rules impacting a user change while the user is on that page.

For example, if a user has a page open where they can see a Thing, then they click a button on that page that changes which privacy rules apply to them such that they can no longer see that Thing, this new privacy rule outcome will not reflect on the page until the page is refreshed.

Managing the security of private files requires configuring specific settings within both the Privacy Rules and the element responsible for uploading the file.

You can learn more about this in our dedicated guide below:

Article: Files
Article section: Uploading private files

Privacy rules are built using two pieces of information:

What are the attributes of the database thing
What are the attributes of the current user

By combining the attributes of these two, we can flexibly set up rules that determine who the user is and what the user is trying to access. Let's look at another rule written out as a sentence to illustrate:

Only return the data if the thing's Creator is the current user

Here we are involving both the thing in question and the current user. If the current user and the creator of the thing is the same, then Bubble will return the data. If they are not, the data stays securely on the server.

Privacy rule settings

Each privacy rule consists of different settings, and the easiest way to understand how they work is to simply read them from left to right like you would an English sentence:

The sentence above says "When the current user is logged in, users who match this rule can view all fields". Since we are working on the data type Product (visible in the header of the form), we could extend that sentence to "When the current user is logged in, users who match this rule can view all fields on the product".

The settings and their labels are meant to be taken literally. For example, View all fields means View all fields – it does not stop making changes to the field in a workflow. Likewise, Find this in searches applies to Do a search for specifically – but the record can still be referenced in other ways.

We recommend playing around with the settings and viewing the results on a page to learn how they affect what users can see and do.

Privacy rules and workflows

Do Privacy rules affect your app's workflows? The answer is yes and no.

View all fields does not stop you from Making changes to a thing and updating that field in a workflow. However, it can stop you from correctly checking a condition if the current user is unable to view the field on which the condition is based
Do a search for does not stop you from making changes to a thing, but it can stop you from getting the search results that you want in a workflow. In other words, if you are using the Do a search for data source in a workflow, the search will only return the data that the current user has access to.
Allow auto-binding stops the user from making changes through auto-bound elements – but it does not stop them from making those same changes in a workflow.

There are two important lessons we can take in:

You need to view the workflow as being run by the current user – the same restrictions will apply to the workflow as in any other scenario in your app
To protect workflows from performing tasks you don't want it to, you'll need to use conditional expressions in the Only when field on the workflow or specific action

Can I override privacy rules in a workflow?

Sometimes you'll have a need to override privacy rules when a user takes a specific action. For example:

User 1 does not have permission to search for any other users
When User 1 runs a specific action, you may need to perform a search for all other users to make a change

In other words, you need to override the Privacy Rule that stops User 1 from searching for other users. This is done by using an API Workflow and checking Ignore privacy rules when running the workflow.

This lets you run workflows that perform an important task with full access to data, without compromising your security by opening up the access for the current user. The operation is performed purely server-side, meaning that your users cannot see it or even know that it's running.

Examples

Example 1: Shopping cart

First, we'll set up the example from earlier, but expand on it a little bit. We have a custom data type called Shopping Cart. This type should only be found in searches and viewable by the person who created it. But wait: if no one else can see the order, how are we to deliver the product?

Someone else needs to be able to see it, but it must be restricted. We'll set up a custom field on each user called Admin (yes/no), which grants access to see anyone's cart. On the cart, we can use the already existing and automatically populated Created by field.

The User should look like this:

This setup requires that we set up three privacy rules:

The first gives access to search for and view fields on the cart if you are the one who created it
The second gives access to search for and view fields on the cart if your admin field is set to yes
The third is the automatically generated Everyone else rule: this states that everyone else should have no access

Pay especially close attention to the bottom rule, marked in red. This is the one that determines what happens to everyone else. We've unchecked all the boxes in this example, making sure that only admins and cart owners get access.

A good way to think about privacy rules is that the most generous rule – the one that gives the broadest access – will always override any other rules you set up.

With privacy rules, you don't prohibit access, you grant it.

Following that logic, our two top rules are granting access to the cart 1) if you are the cart's creator, or 2) if you are an admin, as specificed by the Admin yes/no field.

In this example, we'll look into how properties on the data type to which the privacy rules are applied can further grant access under certain circumstances.

Let's imagine we have a task management app, where access to tasks follow two simple rules:

The creator of the task has full access to their tasks
The creator can invite other users into a specific task, granting them access

In that case, we need some way to determine whether a user has been invited to a specific task. Keep in mind, we want to add that permission only to certain tasks, not all of them.

We can solve this by adding a new custom field on the Task data type that contains a list of all Users who have been invited to it. The database structure can look like this:

Whenever we want to give someone access to the Task, we add their name to the list using workflow:

Since the Invited users field is set to be a list, Bubble lets us use the add function that will add that single user to the list of Invited Users (if we wanted to add a list of users we would use the add list function).

Now, to set up our privacy rule, we will again need three rules:

The first states that if the current user is the , you should have access
The second states that if the current user is in the list of invited users, you should have access
The third (everyone else) states that no one else should have access

In the privacy rule editor it will look like this:

Again we can see that the two rules grant access under special circumstances, while the bottom does not grant the permission to everyone else.

Ending notes

Privacy rules are the most important safeguard you have to protect your user's data, and we strongly encourage that you get to know them well and make a habit of setting up data to be secure from day one. Privacy Rules act on the server-side, making it impossible for data to be stolen, tampered with or accidentally leaked, since the information never leaves the server

Bubble has strong security features in place, but we don't enforce them. It's up to you as the developer of the app to use them in the right way to make sure your user's private data stays private.