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

Follow me:

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.
CleanShot 2021 06 23 at 15.56.55
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.


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


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:

this user is current user bubble

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

upload private file bubble
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:

file permission denied

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.

make changes to thing 1
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.

Support the site and keep it free ❤️

I love tech startups and the Bubble community, and have made it my mission to try and create content that’s valuable, easy to follow and entertaining.

Creating content next to full-time consulting work is time-consuming; if you’d like to support it and keep the site free for everyone, please consider buying me a coffee or becoming a supporting member.

Buy Me A Coffee

Follow me:
Bubble.io books

Learn Bubble the right way

Our professional Bubble books teach you how to plan, structure and build your applications right from the start.

5-star review stars

More Posts


June 24, 2021 at 09:27

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

    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.

December 27, 2021 at 19:32

Hi Amelie Solutions,
Have you set up Algolia and know a way how to add privacy rules in Bubble for the searches?

From what I understand you need to check the “everyone else” option in the privacy tab.
However, we would like to use Algolia for sensitive data and are wondering whether there is any way to solve this?

Since this is quite urgent for us, we would be willing to pay to get some support for this issue asap.

    Petter Amlie
    December 27, 2021 at 22:15


    Unfortunately, Bubble’s Algolia integration doesn’t support Privacy Rules. You may be able to add a level of privacy/filtering by connecting directly to Algolia through the API connector, but out of the box the built-in Algolia features are not meant for sensitive data unfortunately.

    Petter Amlie
    December 28, 2021 at 14:50

    I’ve seen Typesense mentioned as an alternative for this in a forum post asking the same question (may have been your post..?). I’m not familiar with it myself, but it may be worth checking out as an alternative.

mark pereira
February 23, 2022 at 23:52

Hello Petter: Sending you gratitude for Bubble – Ultimate Guide! Excellent value! I need to know when we can expect your Bubble Security Book? Hope you will reply.

    Petter Amlie
    February 25, 2022 at 19:38

    Hi Mark! Thanks for the great feedback! The security book is moving closer to release as we speak, but I can’t set an exact date. I’m expecting within the next 30 days.

    You’ll receive an email upon its release!

Viquar Ahmed
July 28, 2022 at 12:23

If i have multiple privacy rules on single table then how it will work
– Will it overrides or which rule priority comes first?

By the way I recently bought your 2 books (Performance & Security)
– After reading those books i feel i get some super powers…

Hope you will write another book related “Bubble SEO”…

    Petter Amlie
    August 4, 2022 at 10:36

    The Privacy Rules are additive, meaning that the most “generous” one (the one that gives the broadest set of permissions) will overrule any stricter rules (provided that the conditions are fulfilled, obviously).

    Thanks for the comments about the book! I am considering new book projects, but not sure yet what that to cover. Thanks for the input!

Will Ericksson
September 19, 2022 at 07:13

Great article Petter – as always!! The developer tools example is great. 👏

November 7, 2022 at 10:10

hi, I’m be interested in Privacy Rules may I have a Electronics book of security?

    Petter Amlie
    November 8, 2022 at 10:04

    Hi there, I have a full-length book on security available as a paid download here: https://www.amliesolutions.com/books/the-ultimate-guide-to-bubble-security/

      November 23, 2022 at 00:13

      Hi Petter,
      Thanks for this neat documentation.
      I have a question regarding data tables relation with privacy rules in combination with a server side plugin.

      For instance I have an Offer table which has a field of type List of Articles. I pass a List of Offers to my plugin in which I iterate on Offers and retrieve the articles of Each offer in a loop. My plugin does not seem to see the attached Articles as soon as I apply Privacy rules.

      Thanks in advance

        Petter Amlie
        December 7, 2022 at 10:55

        Hi there,

        Am I getting you correctly that you’re doing this in a backend workflow? Have you tried checking Ignore privacy rules when running the workflow? Backend workflows are flexibl when it comes to respecting Privacy Rules as you sometimes need them to update data without being constrained by the Current User’s restrictions.

      November 27, 2023 at 23:43

      Hi Petter,
      I’m in the process of reading the security book and am at the part about searches and lookups. In the book you say that a lookup (ex: Current User’s Company) supersedes the privacy rules and so do url parameters but when I tried it in the bubble editor as a test the privacy rules prevented me from seeing the data of both url parameters and a lookup from a satellite data type. Was wondering if bubble had changed how privacy rules affect these or if I’m somehow causing this from another source?
      Both the performance and security book are great. Hope to hear for you soon.

        Petter Amlie
        December 8, 2023 at 11:35

        Hey Mike!

        This one’s a bit more complicated than that. It’s not that it supersedes privacy rules in the way that data in protected fields are exposed. The potential security concern is that when you provide a unique ID, Bubble will return the data type itself (even if its fields are hidden. This has two implications:

        1) It confirms to anyone looking that there is a thing with that unique ID.
        2) Privacy rules don’t protect workflows, so since the thing is loaded to the page, a Make changes to a thing action may still write to protected fields unless protected with a server-side condition. If you have a form with a Save button for example, a malicious user can replace the unique ID in the URL parameter and run the workflow successfully, making changes to a thing they’re not supposed to have access to. Again, server-side conditions can stop this from happening.

        Hope that made it clearer!

November 23, 2022 at 11:27

Hi Petter,

I have a question around the combination of:
– related Things with Privacy rules, for example I have a Thing type Offer whose field offer_items is a List of Thing OfferItem both visible to Current User is logged in. To ensure data is not visible through the Data Api.
– a plugin action server side functiom taking in a List of Offer. Which iterates on Offers and in each Offer loop on its OfferItems

The data privacy rules prevent the plugin from seing Offer.offer_items. Is there any trick to go around this ? Or a best practice ?

    Petter Amlie
    December 7, 2022 at 10:56

    See my other response. Let me know if this helps!

Leave A Reply

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


Email icon

Useful articles and tips

Join the mailing list to get guides, opinions and articles on Bubble, no-code, automation and the tech industry.

We don't share your email address with anyone, and you can unsubscribe at any time.

You have successfully subscribed