Bubble.io Privacy Rules
The most critical — and most often misconfigured — feature in Bubble.io. Privacy rules are your application’s last line of defence against unauthorised data access. This guide shows you how to configure them correctly, completely, and defensively.
What Are Privacy Rules and Why Do They Matter?
Privacy rules in Bubble.io are server-side access control policies configured in the Data → Privacy tab. They define, for each data type, which users can view records, which fields are exposed, and who can create, modify, or delete entries. They are enforced before any data is returned from Bubble’s servers — meaning they cannot be bypassed by manipulating the UI or the browser.
Without correctly configured privacy rules, any logged-in user can search for and retrieve any record of any data type in your application. This is appropriate during development but a critical vulnerability in production. Every production Bubble.io application must have privacy rules configured on every data type.
Server-Side Enforced
Privacy rules run on Bubble’s servers before any data reaches the browser. Frontend manipulation cannot bypass them.
Filter Search Results
Search results are automatically filtered — users only receive records they are authorised to see, even with broad search constraints.
Field-Level Control
Control which fields within a data type are visible — expose a User’s name but hide their email address to non-admin users.
CRUD Permissions
Separately configure who can view, create, modify, and delete records for granular, role-appropriate access control.
Multi-Tenancy
Privacy rules are the mechanism behind tenant isolation in SaaS apps — ensuring Account A cannot see Account B’s data.
Condition-Based
Rules can reference any field, relationship, or expression — enabling complex role-based and relationship-based access patterns.
Anatomy of a Privacy Rule
Navigate to Data → Privacy in Bubble.io. Select a data type from the left panel. You will see a list of permission rules, each with a name, a condition, and a set of permissions it grants. Bubble evaluates rules in order and grants access if any rule’s condition is met.
Rule Name: “Owners can edit their own records”
When: Current User = This [DataType]’s creator
Permissions:
View all fields: ✓
Modify: ✓
Delete: ✓
Create: ✓
// Rule 2 — Public read-only access
Rule Name: “Public can view basic info”
When: Everyone // no condition = applies to all
Permissions:
View fields: title, description, price (only — not private fields)
Modify: ✗
Delete: ✗
Common Privacy Rule Patterns
| Pattern | Condition | Permissions |
|---|---|---|
| Own records only | Current User = This Record's creator |
View all, Modify, Delete |
| Team member access | Current User is in Record's account's members |
View all, Modify (not Delete) |
| Admin override | Current User's is_admin = yes |
All permissions |
| Public read-only | Everyone (no condition) |
View selected fields only |
| Role-based edit | Current User's role = "editor" |
View all, Modify (not Delete) |
| No frontend create | No rule granting Create | Create via backend workflows only |
Multi-Tenant SaaS Privacy Rules
In a SaaS application where every record belongs to a specific Account (workspace), your privacy rules must enforce tenant isolation across every data type. This is the most critical security configuration in any Bubble.io SaaS product.
// Data type: Project (or any app-specific data type)
// Prerequisite: Project has a field “account (Account)”
Rule 1: “Account members can view”
When: Current User is in This Project’s account’s members
Permissions: View all fields
Rule 2: “Account members can create and modify”
When: Current User is in This Project’s account’s members
AND Current User’s account’s subscription_status = “active”
Permissions: Create, Modify
Rule 3: “Account owner can delete”
When: Current User = This Project’s account’s owner
Permissions: Delete
// No rule = no access. Never add “Everyone can view” to private SaaS data.
Test Tenant Isolation Explicitly
After configuring SaaS privacy rules, create two test accounts, add data to each, then check each account’s data via the Bubble.io data inspector logged in as each user. Confirm that zero records from Account A appear when logged in as Account B. Do this for every data type before launching.
Privacy Rule Audit Checklist
-
✓
Every data type in the app has at least one explicitly configured privacy rule
-
✓
No data type relies on Bubble.io’s default (no-rule) behavior in production
-
✓
Sensitive fields (email, phone, payment data) are hidden from public rules — exposed only to owners and admins
-
✓
Admin-only data types have a strict is_admin = yes condition on all permissions
-
✓
Backend-only data types (e.g. Usage Logs, Audit Trails) have no frontend Create permission
-
✓
Tenant isolation tested — confirmed zero cross-account data visibility for all SaaS data types
-
✓
API workflow endpoints have “This workflow can be run without authentication” disabled where not needed
-
✓
File storage privacy reviewed — uploaded files have appropriate access restrictions via Bubble’s file management settings
Frequently Asked Questions
Can users bypass Bubble.io privacy rules through the browser?
No. Privacy rules are enforced on Bubble’s servers before any data is returned to the browser. Even if a user manipulates the frontend, inspects network requests, or uses browser developer tools to forge API calls, the server will not return data they are not authorised to see according to the configured rules.
What happens when no privacy rules are configured in Bubble.io?
Without privacy rules, all authenticated users can view and potentially modify all records of that data type. This is a critical security vulnerability in production applications. SA Solutions recommends configuring explicit privacy rules for every data type as part of the initial architecture phase of every project.
Need a Security Audit for Your Bubble.io App?