Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • Building your first app
        • Planning features
        • Database structure
        • Design and UX
        • eCommerce and payments
          • Shopping cart
          • Checkout page
          • One-time payments
          • Subscriptions
          • Marketplace
      • Creating and managing apps
      • The Bubble editor
        • Tabs and sections
          • Design tab
            • The element tree
            • The property editor
          • Workflow tab
          • Data tab
          • Styles tab
          • Plugins tab
          • Settings tab
            • Application settings
              • Custom headers/body
              • Visual settings
              • Social media sharing
              • Translating your app
              • Email settings
              • Collaboration
            • Custom domain and DNS
          • Logs tab
        • Tools
          • Key features
          • The search tool
          • The Issue Checker
          • The element tree
          • The element property editor
          • The debugger
          • Notes
        • Previewing your app
      • Transitioning to Bubble from...
        • JavaScript
        • HTML and CSS
        • SQL
    • Design
      • Elements
        • The element hierarchy
          • The element tree
        • The page
        • Containers
          • Groups
          • Repeating groups
          • Table elements
          • Popups
          • Floating groups
          • Group focus
        • Visual elements
        • Input forms
          • Text and numbers
          • Dates and time
          • File uploads
          • Selection controls
        • Reusable Elements
      • Styling
        • Color variables
        • Font variables
        • Styles
        • Custom Fonts
      • Responsive design
        • Building responsive pages
        • Legacy articles
          • The Basics (Legacy)
          • Building Responsive Pages (Legacy)
          • Migrating Legacy Pages
          • Tips When Designing (Legacy)
      • Templates
      • The Component Library
      • Importing from Figma
    • Data
      • The database
        • Data types and fields
        • Creating, saving and deleting data
        • Finding data
        • Displaying data
        • Protecting data with privacy rules
        • The database editor
        • Export/import data
          • Exporting data
          • Importing data (CSV)
        • Working with location data
        • Using Algolia
        • Database structure by app type
          • Marketplace Apps
          • Directory & Listings Apps
          • Social Network Apps
          • SaaS Apps
          • Project Management Apps
          • CRM Apps
          • Professional Services Apps
          • On-demand Apps
          • Documentation/ CMS Apps
          • Applicant Tracking System (ATS) Apps
          • Portfolio Apps
          • Gallery Apps
          • Online Store / Ecommerce Apps
          • Blog Apps
          • Messaging App
          • Dashboards
          • Building Block Apps
          • Bubble as a backend
      • Files
      • Images
      • Static data
        • App texts (translations)
        • Option sets
      • Temporary data
        • Custom states
        • URL parameters
      • User accounts
        • Authentication plugins
          • Facebook plugin
          • Fitbit plugin
          • Google plugin
          • Instagram plugin
          • LinkedIn plugin
          • Pinterest plugin
          • Slack plugin
          • Wistia plugin
          • YouTube plugin
        • Cookies set by Bubble
      • Time, dates and time zones
    • Logic
      • The frontend and backend
      • Workflows
        • Events
          • Frontend events
            • Recurring workflows
            • Custom events
          • Backend events
            • Database trigger events
        • Actions
        • API Workflows
      • Dynamic expressions
      • Conditions
      • Navigation
        • Single-page applications (SPA)
        • Multi-page applications
        • Page slugs
    • Workload
      • Understanding workload
        • Activity types
        • The workload calculation
        • Client-side and server-side processing
      • Tracking workload
        • Measuring
          • Using App Metrics
        • Monitoring
          • Workload notifications
          • Infinite recursion protection
      • Optimizing workload
        • Optimization framework
        • Optimization checklist
          • Page load
          • Searches
          • Workflows and actions
          • Backend workflows
        • Agency showcases
          • Minimum Studio
          • Neam
          • Support Dept
    • Security
      • Bubble's security features
      • Planning app security
      • Client-side and server-side
      • Bubble account security
      • App security
      • Page security
      • Database security
      • API security
        • API Connector security
        • Data API security
        • Workflow API security
      • Flusk
        • Overview
        • Flusk plan features
        • Getting started with Flusk
        • Flusk security tools
          • The Issues Explorer
          • Issue details
          • Tools and settings
            • Pages rating
            • Database rating
        • Flusk FAQ
      • Cookies
      • Security checklist
    • Publishing your app
      • Web app
      • Native mobile app
        • Global native mobile settings
        • iOS App Store
        • Google Play Store
        • Publishing FAQ
    • AI
      • Generate apps with AI
        • About AI app generation
      • AI page designer
      • Connect to AI agents
    • Maintenance
      • Collaborators
      • Version control
        • Best practices: Version control
        • Transitioning from the legacy version control
        • Terminology: Version control
        • Version Control (legacy)
      • Commenting
      • Database maintenance
        • Copying the database
        • Restoring database backups
        • Bulk operations
          • Bulk operation methods compared
        • Wiping change history
      • Performance
        • Hard limits
        • Capacity Usage (legacy)
        • Notes on queries
      • SEO
        • Introduction to SEO
        • SEO: App
        • SEO: Page
      • Testing and debugging
        • Introduction to testing and debugging
        • The debugger
        • The server logs
        • Supported browsers
      • API workflow scheduler
    • Integrations
      • API
        • Introduction to APIs
          • What is a RESTful API?
        • The Bubble API
          • Bubble API terminology
          • Authentication
            • How to authenticate
            • No authentication
            • As a User
            • As an admin
          • The Data API
            • Data API Privacy Rules
            • Data API endpoints
            • Data API requests
          • The Workflow API
            • Workflow API privacy rules
            • Workflow API endpoints
            • API workflows
              • Creating API workflows
              • Scheduling API workflows
              • Recursive API workflows
              • API Workflow Scheduler
              • Case: Stripe notifications
        • The API Connector
          • Authentication
          • API Connector security
          • API guides
            • OpenAI
              • Authentication
              • Calls
                • ChatGPT
                  • Chat
            • Google Translate
              • How to setup Google API keys
          • Streaming API
        • API security
        • Plugins that connect to APIs
        • API Glossary
      • Plugins
        • What Plugins Can Do
        • Installing and using Plugins
        • Authentication plugins
        • Special Plugins
      • SQL Database Connector
      • Bubble App Connector
      • WorkOS
        • WorkOS SSO
        • WorkOS API
    • Infrastructure
      • Sub-apps
      • Bubble release tiers
      • Hosting and scaling
        • How Bubble hosting works
        • Scaling with Bubble
        • CDN (Cloudflare)
        • Bubble app names
        • Domain and DNS
      • Compliance
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks and standards
    • Bubble for Enterprise
      • Hosting and infrastructure
        • Dedicated instance
          • The Dedicated editor experience
          • Technical specs
          • Main cluster dependencies
          • Customizable options
          • Migration process
            • Pre-migration
            • During migration
            • Post-migration
      • Security and compliance
        • Single sign-on (SSO)
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks
        • Bubble's security features
      • Admin and collaboration
      • Priority support
      • Billing and Payment Guideline for Dedicated Instances
  • Core Reference
    • Using the core reference
    • Bubble's Interface
      • Design tab
      • Design tab (Legacy)
      • Workflow tab
      • Data tab
      • Styles tab
      • Styles tab (Legacy)
      • Plugins tab
      • Settings tab
      • Logs tab
      • Template tab
      • Toolbar
      • Top and context menu options
      • Deployment and version control
        • Deployment & Version Control Dropdown (legacy)
      • Notes
    • Elements
      • General properties
      • General properties (Legacy)
      • Styling properties
      • Styling Properties (Legacy)
      • Responsive Properties
      • Responsive Properties (Legacy)
      • Conditional formatting
      • States
      • Page Element
        • Page Element (Legacy)
      • Visual Elements
      • Containers
      • Container Layout Types
      • Containers (Legacy)
      • Input Forms
      • Reusable Elements
      • Element Templates (legacy)
    • Workflows
    • Events
      • General events
      • Element events
      • Custom events
      • Recurring event
      • Database trigger event
    • Actions
      • Account
      • Navigation
      • Data (things)
      • Email
      • Element
      • Custom
    • Data
      • Data Sources
      • Operators and comparisons
      • Search
      • Privacy
    • Styles
    • API
      • The Bubble API
        • The Data API
          • Authentication
          • Data API endpoints
          • Data API requests
        • The Workflow API
      • The API Connector
        • Authentication
        • Adding calls
    • Bubble-made Plugins
      • AddtoAny Share Buttons
      • Airtable
      • API Connector
      • Blockspring
      • Box
      • Braintree
      • Bubble App Connector
      • Chart.js
      • Circle Music Player
      • Draggable Elements
      • Dropzone
      • Facebook
      • Fitbit
      • Full Calendar
      • Google
      • Google Analytics
      • Google Optimize
      • Google Places
      • Ionic Elements
      • iTunes
      • Slidebar Menu
      • LinkedIn
      • Localize Translation
      • Mixpanel
      • Mouse & Keyboard Interactions
      • Multiselect Dropdown
      • Progress Bar
      • Rich Text Editor
      • Rich Text Editor (Legacy)
      • Screenshotlayer
      • SelectPDF
      • Slack
      • Segment
      • Slick Slideshow
      • SQL Database Connector
      • Star Rating
      • Stripe
      • Tinder-like Element
      • Twitter
      • YouTube
      • Zapier
    • Application Settings
      • App plan
      • General
      • Domain / email
      • Languages
      • SEO / metatags
      • API
      • Collaboration
      • Sub-apps
      • Versions
  • Account & Marketplace
    • Account and billing
      • Pricing and plans
        • Plans and billing
        • Billing cycle
        • FAQ: Pricing and Workload
      • Account Management
      • Building Apps for Others
      • Selling on the Marketplace
      • Plans & Billing (legacy)
    • Official Bubble Certification
      • Hiring certified developers
    • Building Plugins
      • The Plugin Editor
      • General Settings
      • Updating to Plugin API v4
      • Adding API Connections
      • Building Elements
      • Building Actions
      • Loading Data
      • Publishing and versioning
      • Github Integration
    • Building Templates
    • Application and data ownership
    • Marketplace policies
    • Bug reports
  • Vulnerability Disclosure Policy
  • Beta features
    • About the Beta features section
    • Native mobile apps 🔒
      • Introduction
        • What is a native mobile app?
        • Native mobile vs. web development
        • Differences in native and web elements
        • Native mobile app terminology
      • Building
        • Views and navigation
        • Native mobile actions
        • Components and gestures
        • Device resources
          • Location services
          • Camera/photo library
      • Previewing
      • Publishing
Powered by GitBook
On this page
  • What are Privacy rules?
  • Client-side data
  • How privacy rules work
  • Privacy rule settings
  • Privacy rules and workflows
  • Examples
  • Example 1: Shopping cart
  • Example 2: Sharing tasks
  • Ending notes
  • Other ways to learn

Was this helpful?

  1. User manual
  2. Data
  3. The database

Protecting data with privacy rules

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

Last updated 5 months ago

Was this helpful?

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 .

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.

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:

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:

  1. User 1 does not have permission to search for any other users

  2. 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:

  1. The first gives access to search for and view fields on the cart if you are the one who created it

  2. The second gives access to search for and view fields on the cart if your admin field is set to yes

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

Example 2: Sharing tasks

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:

  1. The creator of the task has full access to their tasks

  2. 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:

  1. The first states that if the current user is the , you should have access

  2. The second states that if the current user is in the list of invited users, you should have access

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

Other ways to learn

Video lessons
Books

Article:

Article:

Article:

Article section:

by Petter Amlie

Data API Privacy Rules
Workflow API Privacy Rules
Files
Setting up privacy rules
The Ultimate Guide to Bubble Security
core reference entry
Uploading private files
Instead of viewing at a complex dashboard with different settings, it can be useful to simply read it out from left to right as a sentence.
Using an API Workflow, we can override Privacy Rules to get access to data that the current user is prohibited from seeing. It all happens securely on Bubble's server and never reaches the current user's device
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.
These three simple rules is all we need in this scenario.