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

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

For example, you could allow your products to be viewable only by people who are logged in. Written out in plain terms, the rule would be:

Only return the data if the current user is logged in

The logic here is that you ask the server for information using a data source like Do a search for and an operator like Product's Name to show a product's name. If the privacy rule above is active, Bubble only returns the data if the query came from a logged-in user.

This is essential to app security because it's stopped on the server side. The data stays encrypted in the database instead of being sent to the browser, where it could be viewed.

As illustrated above, 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 exploring privacy rules further, it's important to understand that any data reaching your user's device is, by definition, no longer secure. As long as data has been downloaded to a user's device, even if it isn't displayed anywhere in your app, the person using that device can access it by looking at the data traffic being sent to and from the Bubble server.

This is a fairly technical subject. Suffice it to say that the only way data remains truly inaccessible is to make sure it isn't sent from the server in the first place, and privacy rules are how you do that.

It's also worth stressing that in most cases, you want data to reach the device. If it didn't, you wouldn't be able to work with data at all. The task is making sure only the intended information is sent, and no unauthorized data.

In an eCommerce store, you'd likely have data with different security requirements:

Products are known as public data, and the shopping cart is private data.

Bubble has a privacy rule editor that lets you control the privacy settings for all your data types in one central place. You'll find it by going to the Data tab and clicking Privacy.

Privacy rules protect your data types in the following ways:

Privacy rules are built from two pieces of information:

By combining these two, you can flexibly set up rules that determine who the user is and what they're trying to access. Here's another rule written out as a sentence:

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

This involves both the thing in question and the current user. If the current user and the creator of the thing are the same, Bubble returns the data. If they aren't, the data stays securely on the server.

The Privacy section is split into two panels. On the left is a list of every data type in your app, each showing its current status, either Privacy rules applied or Publicly visible. If you have a lot of data types, you can filter the list with the search box above it.

You'll find privacy rules in the Data tab and Privacy section.

Select a data type to see its rules on the right. A data type can have several rules, and each one can be given a name that describes who it covers, such as "User's own data." Click New rule to add another. Each rule can be collapsed while you work, and deleted or commented on using the icons in its header. If a data type has many rules or fields, the Search rules and fields box helps you find the one you're after.

The genereal steps to create a new privacy rules are as follows. We'll cover more details and examples further down in the article:

Each privacy rule is made up of several settings, and the easiest way to understand them is to read them from left to right, like an English sentence.

The sentence above says:

The settings and their labels are meant to be taken literally. View all fields means view all fields. It doesn't stop someone from 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.

Each field on the data type gets its own row, with a checkbox for View, Constraint, and Auto-bind. Each row also shows the field's type, such as text, image, date, or a data type like Post, which helps when you're deciding how sensitive a field is.

A few things make the list easier to work with on data types that have many fields:

Some fields show a dash instead of a checkbox in the Auto-bind column. These are fields that can't be auto-bound at all, such as built-in fields like Created Date and Modified Date.

There's 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 the fields required for privacy checks only need to reach one level in their expression.

In the example above, instead of checking the cart's creator's X, we check the current user, reducing the levels from two to one.

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

There are two important lessons here:

Sometimes you'll 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. You do this with an API workflow, 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 security by opening that access up to the current user. The operation runs purely server-side, so your users can't see it or even know 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 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 never appears on screen, but it can be inferred from the records the search returns.

Search privacy modes are how you close that gap.

You set the search privacy mode in the Settings tab, in the General section. 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 defined on one of your app's pages or workflows. If it finds a match, it allows the constraint. If it doesn't, 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 strict mode. 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 with the Uses constraint field operator to find where specific fields are used as constraints. The payoff is predictable search permissions: 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.

Say you have a custom data type called Shopping Cart. It should only be found in searches and viewable by the person who created it. But if no one else can see the order, how do you deliver the product?

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

The user should look like this:

We set up a simple yes/no field to separate admin users from regular users. Note that we have set the default value to no to make sure that new users are not an admin by default.

This setup requires 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 its boxes here, making sure 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.

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

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

This example looks at how properties on the data type itself can grant access under certain circumstances.

Imagine a task management app where access to tasks follows two simple rules:

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

You can solve this by adding a custom field on the Task data type that holds a list of all users invited to it. The database structure can look like this:

Whenever you want to give someone access to a task, you add them to the list using a workflow:

Since the Invited users field is set to be a list, Bubble lets you use the add function to add that single user to the list of invited users. If you wanted to add several users at once, you'd use add list instead.

Setting up the privacy rule again takes three rules:

In the privacy rule editor, it looks like this:

Again, the two rules grant access under specific circumstances, while the bottom rule does not grant permission to everyone else.

Privacy rules are the most important safeguard you have for protecting your users' data, so it's worth getting to know them well and making a habit of setting data up securely from day one. Privacy rules act on the server side, which keeps data from being 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.