Last updated: October 2026. Written by Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions.

Privacy rules are the single most important security feature in a Bubble.io app, and the one most often misunderstood. They decide which users can see which data. Get them wrong, and one customer may be able to read another’s records, even if your interface looks perfectly tidy.

This guide explains how Bubble privacy rules work, walks through examples for a typical client portal, lists the most common mistakes and shows how to test your rules before launch.

What are Bubble privacy rules?

Privacy rules are conditions you attach to each data type in your Bubble database. They control who is allowed to view that data, based on conditions such as “the current user is this record’s owner”. They are enforced by the platform’s servers, so they protect data even if someone tries to bypass your interface. Hiding a button or a page is not security. Privacy rules are.

How do privacy rules work?

For each data type, you can create one or more rules. Each rule has a condition and a set of permissions that apply when the condition is true. Bubble evaluates the rules for the person asking for the data and grants the matching permissions. Typical permissions include:

There is also a default rule that applies to anyone who matches no other rule. Always check what the default allows for each data type, because anything permitted to everyone else is visible to anyone who can reach your app. Bubble’s interface and options evolve, so check its current documentation.

Example 1: a client portal

Suppose your portal has data types Client, Matter, Document and Message. Roles are Client, Staff and Admin.

The key idea: every sensitive data type has a rule that names who is allowed, and the default for everyone else grants nothing.

Example 2: protecting the User data type

The User data type deserves special care, because it holds emails and personal details. Without restrictions, other users may be able to look up each other. A safer rule lets a user see their own record and lets staff or admins see client records, while hiding sensitive fields such as email addresses from other clients.

What are the most common privacy rule mistakes?

• Leaving data types open to everyone. Review every data type, not just the obvious ones.
• Relying on the interface. Hiding elements or pages does not protect data.
• Forgetting attachments. A record may be protected while its uploaded files remain reachable.
• Ignoring field-level privacy. Internal notes, prices or personal details may need separate protection.
• Storing sensitive data in option sets. Option sets are not protected by privacy rules and are visible to users. Keep them for harmless, shared lists such as statuses and categories.
• Backend workflows that bypass rules. Server-side workflows can be set to ignore privacy rules. Use that only when necessary and design carefully, because data they return or expose may not be protected.
• No testing. Rules that look right often have gaps.

How do you test privacy rules?

1. Create at least two test accounts with the same role, and one of each other role.
2. Log in as the first client and try to access the second client’s records, including by changing IDs in the address and by searching.
3. Log in as the lowest-permission role and attempt every restricted action.
4. Check that files attached to records cannot be opened by the wrong user.
5. Use the editor’s tools to preview the app as another user, and also test with real separate logins.
6. Inspect what data the page loads, not just what it displays.
7. Retest after every significant change.

For the wider picture, read our Bubble.io security best practices guide and how multi-tenant architecture works.

How should you design privacy rules from the start?

• Define roles and who may see what in the PRD, before building.
• Add a field to every record that identifies its owner or customer account, so rules stay simple.
• Start from “no access” and grant only what each role needs.
• Keep rules readable. Complex conditions are easier to get wrong.
• Document the rules so future developers can review them.

Our Discovery Sprint includes roles and access rules in the PRD: $345, delivered in 24 hours and credited toward the build. See also database design mistakes.

What privacy rules do not do

Privacy rules control who can see data. They are not a complete security or compliance programme. You still need secure handling of keys, careful integrations, sensible retention, breach planning and, where regulated data is involved, a qualified adviser. Check obligations that apply to you.

Frequently asked questions

What are privacy rules in Bubble?

Privacy rules are conditions on each data type that decide which users can see its records and fields. They are enforced by the platform’s servers.

Are privacy rules enough to secure a Bubble app?

They are essential but not sufficient. You also need to protect keys, review integrations, test thoroughly and meet any regulatory obligations.

How do I stop one user seeing another user’s data in Bubble?

Add a privacy rule on each data type that only grants access when the current user owns or is authorised for the record, set the default rule to grant nothing and test with two accounts.

Do option sets respect privacy rules?

No. Option sets are visible to users, so never store sensitive information in them.

How do I test privacy rules?

Use at least two accounts per role, try to access each other’s data directly and via search, test attachments and retest after changes.