Bubble Privacy Rules: How to Set Them Up Right

Bubble privacy rules are the server-side conditions that decide who can find, view and change each data type and each field in your app. If you set them before you build workflows, deny access by default and test every role, your users’ data stays private. We build and rescue Bubble apps at Let’s Build My App, and this is the setup routine we want every founder to know.

TL;DR

• Privacy rules are the real lock on your database. Hiding something on the page does not protect the data behind it.
• Start from default-deny: no data returned unless a condition is explicitly met, and only the fields a view needs.
• Set the rules right after you design the database, before you build workflows.
• Test as a logged-out user and as every role you support. Do not trust the front end.
• Linked data types, lists and searches have quirks. Plan for them with helper fields.

Table of Contents

• What Bubble privacy rules actually control
• Why the front end is not protection
• The principles to build every rule on
• How to set up privacy rules, step by step
• A quick reference for common patterns
• The mistakes that leak data
• How to test your privacy rules
• Privacy rules and the rest of your compliance picture
• Our perspective
• When to bring in a build partner
• FAQ
• Sources

What Bubble privacy rules actually control

A privacy rule is a condition attached to a data type. According to a Bubble Tip of the Week, rules tell the server to send data to a user’s browser, or allow changes to the database, only when your conditions are met. That is the key point: the rule runs on the server, before data ever reaches the browser.

Bubble’s own no-code security guide says data leakage is among the most common risks to customer data privacy in no-code apps. It frames the fix as controlling access at two levels: which rows of the database a user can reach, and which fields inside a record they may see.

In practice, each rule lets you decide, per group of users:

• Whether a thing can be found in searches
• Whether it can be viewed, and which individual fields are visible
• Whether it can be linked to from other things
• Whether it can be modified, deleted, or have files attached

The conditions can reference the current user, a field on the thing, a role, or a team. Everything else in your security model sits on top of them.

Why the front end is not protection

This is the mistake we see most often when founders hand us an existing app. A page element hidden with a conditional such as “visible when Current User is admin” hides the element only. As the VibeEval security guide explains, the data still loads from the database, so sensitive elements need the data source gated, not just the visibility.

The same applies to the Data API. The VibeEval guide notes that Bubble’s Data API respects privacy rules only if rules exist, and that you should configure the per-operation toggles (GET, POST, PATCH, DELETE) for each enabled data type. An empty Privacy tab is an open door.

So the working rule is simple: every data type gets explicit rules, and nothing is secured by the UI alone.

The principles to build every rule on

Bubble’s guide boils good configuration down to two practices: default-deny and data minimization. Default-deny means a user gets no data unless a condition is explicitly met. Data minimization means exposing only the fields a given view needs.

The same guide recommends configuring privacy rules before you build your first workflow. We agree, and the reason is structural. Retrofitting rules is hard when the data structure was not designed for them, and sometimes you must add redundant relationships or fields afterward to make a rule possible.

How to set up privacy rules, step by step

Open the Data tab in the Bubble editor, choose the Privacy sub-tab, and work through each data type.

1. Start with the user data type

The User type is where most sensitive fields live: email, phone, billing details, role. Create a rule for the user themselves and make sure other users see only what they truly need, such as a display name. Do not leave email or role visible to “everyone else” just because a profile page shows a name.

2. Add a rule for the owner

Bubble’s default rule, “Visible to creator”, means whoever created a thing can find and view it, as described in the Bullet Launch privacy rules docs. That is a sensible start for user-owned content, but it is a starting point. Check what the unchecked permissions for “Everyone else” are on every type, and confirm them rather than assuming.

3. Add rules for each role or team

A typical B2B app has an admin, a manager and a member, or several customer organizations sharing one database. Write one rule per group, with a condition like “Current User’s organization is This Project’s organization”. If your app has more than two or three roles, design them on paper first. Our guide to RBAC for apps covers how to model roles so the rules stay readable.

4. Restrict fields, not just records

A rule that grants view access to a record usually grants access to its fields too, unless you narrow it. Go through the field list for each rule and uncheck what that group should not see: salaries, internal notes, payment details, admin flags. If a view needs only three fields, expose only three.

5. Decide find versus view

“Find in searches” and “view all fields” are separate permissions. A group that can find a record can list it in a search result. Give search access only to groups that need to list records, and be aware of one quirk: per a Bubble forum thread, searching for a thing by its unique ID returns a result regardless of privacy rules, though the fields stay protected. Do not rely on “find in searches” alone to hide a thing’s existence.

6. Handle linked data types with helper fields

This is where rules get tricky. The Bullet Launch docs point out that rules built on a path like “This Thing’s X’s Y” cannot grant search access. If you want project details visible only to a team, add helper fields, such as the team or organization, directly on the thing you are protecting.

The same logic applies to deep chains. A forum discussion on lists versus relational tables notes that privacy expressions can only go so many tables deep, and that a simple access list kept on the user, in direct contact with the organization, can help. Storing the organization or project directly on each message or task is a small cost for a rule that actually works.

7. Group conditions with care

Complex conditions with “or” and “and” can be ambiguous. A forum thread on the “or” operator in privacy rules explains that the older expression composer evaluated strictly left to right, and that enabling parentheses or the newer composer removes the ambiguity. Group your conditions explicitly, then test them.

A quick reference for common patterns

The pattern is the same in every row: put the thing you filter on directly on the record being protected.

The mistakes that leak data

These come up again and again when apps are reviewed before launch.

• Empty or missing rules. A data type with no explicit rule is a risk. Review each type, including small ones like settings and logs.
• Hidden but not protected fields. If a field is not covered by a privacy rule, it can be readable through the API even when no page shows it.
• Conditions that depend on empty values. A rule that references a field that is empty or a user that was deleted may stop doing what you intended. Write conditions that fail closed, and test edge cases such as a deleted account.
• Visibility conditionals used as security. Covered above, and worth repeating.
• Building first, securing later. Bubble’s own engineers say it is relatively simple to set up rules that protect an app well, yet easy to let some data slip through accidentally.

If your app handles health information covered by HIPAA, talk to legal counsel before you build, since Bubble’s own security guidance does not recommend the platform for apps that require HIPAA compliance, per its security guide.

How to test your privacy rules

Testing is where good rules become trustworthy rules. Use several methods together.

1. Create a test account for every role. Log in as each one and try to view another role’s pages, call another role’s workflows and query data that role should not see. This approach is laid out in the VibeEval guide.
2. Use “Run as” in the editor. A forum thread on testing privacy rules recommends viewing the app as a different user, then using the debugger and the Issue Checker.
3. Build a privacy tester page. A community walkthrough suggests a blank page with a table element per data type, all fields as columns, and the source set to a search for all things of that type. Open it as a logged-out user and as each role. Anything that appears is leaking.
4. Run Bubble’s security dashboard. Bubble describes a dashboard that checks whether privacy rules protect against a logged-out user reaching sensitive data, and it has a button that jumps to the problem in the editor, per Bubble’s comparison page.
5. Work through a pre-launch checklist. Bubble’s guide lists reviewing that every data type has explicit rules, scanning for exposed secrets, auditing public pages, testing role boundaries as a standard user trying admin pages, and confirming HTTPS. See the full checklist, and our own post on what to check before you launch.

A caution from AppSecure’s testing guide: one unchecked box or an overly permissive condition exposes records, and it will not show up from the front end. Good testing needs editor-level access, not just clicking around the live app.

Privacy rules and the rest of your compliance picture

Privacy rules control who can see data inside your app. They do not answer where data is stored or which laws apply to the people in it. If you serve European users, read our guide to GDPR for startups. If a customer asks where your data lives, see data residency for US apps. Rules that are clean and documented make both conversations much easier.

Performance matters too. Overly complex rules that traverse many links can slow a page, and our Bubble performance playbook shows how to find the cause. Simple helper fields help security and speed at once.

Our perspective

We review Bubble apps built by founders and by other teams, and the pattern is consistent: the product works, the screens look right, and the privacy tab was never finished. Nobody did anything careless. Privacy rules just do not announce themselves, because the app behaves the same whether they are set or not.

Our approach is to treat the data model and the rules as one design job, done in the first days of a project, not a cleanup task at the end. Our team is senior US-based engineers, and you work directly with the people doing the build, so the person who designs your tables is the person who writes your rules.

We also choose the platform based on what your product needs. For many MVPs, Bubble is the fastest route to market, and we ship most projects in 6 to 10 weeks. When a product outgrows no-code, we run Bubble-to-code migrations so the security model moves into production-grade software without starting from zero.

If you are not sure what your rules currently allow, that is a good first conversation to have with us.

Alex

When to bring in a build partner

If you are launching your first product, handling customer data for the first time, or inheriting an app with unclear rules, getting the rules designed with the data model saves rework. Our MVP development work sets up roles and privacy rules from the start, and our project rescue service is for apps that already exist and need an engineering partner behind them. If your product has outgrown Bubble, see our Bubble-to-code migration service.

Pricing is fixed and agreed up front, with no hidden costs. Our published plans are Starter at $1,750 per month, Growth at $3,000 per month and Enterprise at $5,000 per month, with a Custom option too. See the pricing page for what each includes.

Ready to launch your project with rules you can trust? Contact us and tell us what your app stores and who needs to see it.

FAQ

Are Bubble privacy rules on by default?

Bubble creates a default “visible to creator” style rule for new types, as described in the Bullet Launch docs. Do not depend on defaults, though. Open the Privacy tab for every data type and set explicit rules, because the Data API only respects rules that exist.

Can I hide a field without a privacy rule?

Hiding a field in the interface does not stop it from being delivered to the browser. The VibeEval guide explains that the data still loads, so you need a privacy rule that removes the field from users who should not see it.

Why can’t I use a linked data type in a search rule?

Per the Bullet Launch docs, rules using “This Thing’s X’s Y” cannot grant search access. Store the organization, team or project directly on the thing you want to protect, and base the rule on that field.

How do I check whether a logged-out visitor can see my data?

Build a blank test page with a table per data type and open it while logged out, as suggested in this community walkthrough. Anything that displays is visible to the public and needs a rule.

When should I set privacy rules?

Right after you design the database and before you build workflows, as Bubble’s guide recommends. Rules are far easier to write when the data structure was planned with them in mind.

Sources

• Bubble: No-Code Security, Essential Controls and Risk Guide
• Bubble: Customer Data Privacy, How to Protect User Data
• Bubble: Bubble vs Base44 comparison
• VibeEval: How to Secure Bubble
• Bullet Launch Docs: Privacy rules
• Bubble Forum: Bubble lists versus traditional relational tables
• Bubble Forum: Return data action returns single item but null for a list
• Bubble Forum: Unsure about “or” operator in privacy rules
• Bubble Forum: Is there an easy way to test if privacy rules break anything?
• Bubble Forum: Security, how to avoid database leaks on your Bubble app
• AppSecure: Penetration Testing for Bubble Applications

Recommended

• RBAC for Apps: How to Design and Build Roles That Hold Up
• Stop Leaking Keys: Secure Bubble API Connector and the :join Fix
• No-Code Security: What to Check Before You Launch

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.