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.

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:

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 authentication and authorization before it's completed or rejected.

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:

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

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:

Privacy rules are built using two pieces of information:

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:

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.

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

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 fetched 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.

There's is an important limitation to be aware of when conditions reference related data more than one level deep.

Privacy rules can evaluate fields that belong directly to the data type, but they can't traverse multiple layers of relationships to grant search access. If a rule uses a chained reference, such as accessing a field on a related thing and then another field beyond that, Bubble can't use that rule to grant search access.

To avoid this limitation, structure your data so that the fields required for privacy checks only need to access one level in its expression:

In the example above, instead of checking the Cart's Creator's X, we're checking the Current User, reducing the levels from 2 to 1.

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

There are two important lessons we can take in:

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

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.

Search privacy modes control which fields a user can filter on when they search.

When you set up a Do a search for, you can narrow the results using constraints. A constraint is a filter, such as Salary > 100,000 or Status is "approved".

A user can learn something about a field without ever viewing it. Imagine a Salary field that's protected by a privacy rule. The user can't see the number, but if they're allowed to search with the constraint Salary > 100,000, the records that come back tell them who earns more than that. The field's value doesn't directly appear on screen, but can be inferred through the records that the search returns.

Search privacy modes are how you close that gap.

You set the search privacy mode in Settings – General. The setting applies to the application branch you're working in.

Automatic mode protects your data without breaking the searches your app already relies on. To do that, it looks at where each search comes from.

When a search runs, Bubble checks whether the constraint and its operator match one that's defined on one of your app's pages and/or workflows. If it finds a match, it allows the constraint. If it doesn't find a match, the constraint is only allowed when you've granted permission for that field.

Searches made through the Data API always need explicit permission. They run outside the context of your pages, so Bubble has no page-defined search to match them against.

As long as your app handles any kind of private data, we recommend using Strict mode. This means no field can be used as a search constraint unless you've explicitly allowed it, which removes the search inference risk across every field at once.

Strict mode takes a little more setup. You'll need to allow constraints on the fields your searches depend on, and we recommend using the search tool and the Uses constraint field operator to find instances where specific fields are used as constraints. The payoff is that your search permissions become predictable: a field is constrainable only when you say so, with no behind-the-scenes matching.

Automatic mode is a strong default while you get there. It protects undefined constraints, including Data API searches, without breaking the searches already built into your pages.

Off mode gives no constraint protection, so we only recommend it for apps that hold no private data.

This setting controls which fields a user can use as a search constraint.

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:

Pay especially close attention to the bottom rule. 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 they're additive: every rule a user matches contributes its permissions, and those permissions stack up. The user ends up with the combined access of all matching rules, not the strictest one.

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:

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:

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.

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 offers a robust set of security features for you to take advantage of. As the developer, it's up to you to use them correctly to keep your users' private data private.