Bubble data exposed because privacy rules are not set: how to fix it

To fix a Bubble app that exposes data because privacy rules are not set, add at least one privacy rule to every data type that holds personal or private data, and clear all boxes in the Everyone else rule. Then close the Data API for each type that does not need it, and test as a logged-out visitor and as a normal user.

This guide shows how to confirm the problem, how to fix it in order of urgency, and how to check whether someone read your data. It also shows how to keep the rules correct when you add new data types.

What does “privacy rules not set” mean in Bubble?

It means that a data type has no rule that limits who can see its records. Bubble uses privacy rules to decide which users can read, search, and change the data. Bubble’s own glossary says that it uses privacy rules “to protect data in the database from ever leaving the server.”

A type without rules has no such protection. The Bubble editor marks each data type as either “Privacy rules applied” or “Publicly visible”. The Bubble article on privacy rules does not state the default in words. The label tells you what to expect. Treat each type that shows “Publicly visible” as open to every visitor.

A privacy rule is a condition plus a set of permissions. The condition says which users the rule applies to. The permissions say what those users can do. The Bubble manual page on privacy lists the main permissions: find this in searches, view all fields or chosen fields, auto-binding, and the Data API permissions.

Pay attention to one more rule: when several rules apply to a user, Bubble gives the user access if any one rule grants it. A wide rule cancels a narrow rule. Keep each rule narrow.

Founders miss this problem because the app looks correct. A page that shows only your own orders looks private. If the type has no rule, the browser can still receive all the orders.

How can I confirm that my Bubble data is exposed?

Use the Security Dashboard first. Then test the app as an outsider. Both checks take less than an hour for a small app.

Check 1: Read the Security Dashboard

The Bubble editor has a Security Dashboard with an Issue Explorer. The Bubble issue details article lists these issues that match this problem:

Open each issue and write down every data type that it names. This is your work list. The dashboard marks a type as sensitive with a prediction model or with a manual mark. It can miss a type. Do not trust a clean dashboard alone.

Check 2: Read the data tab yourself

1. Open the Data tab of the editor and go to the privacy settings of the types.
2. Write down each data type and its label: “Privacy rules applied” or “Publicly visible”.
3. For each type with rules, open the Everyone else rule. Check which boxes are on.
4. For each type, ask one question: would I accept that a stranger reads every field of every record? If the answer is no, the type needs a rule.

Check 3: Test as a logged-out visitor

1. Open your app in a private browser window. Do not log in.
2. Open DevTools and select the Network tab.
3. Visit the pages of your app and look at the responses. Look for JSON that contains names, emails, or other private fields.
4. If your app uses the Data API, call it without a token. Replace the type name with one of your types:

curl -s "https://your-app.bubbleapps.io/api/1.1/obj/user"
curl -s "https://your-app.bubbleapps.io/api/1.1/obj/order"

The /api/1.1/obj/<type> path is the standard form of the Bubble Data API. If your app uses a custom domain or a version path, use that. A 200 response with records means the type is open through the API. A response that says the access is not allowed is the correct result.

The Bubble manual says that Data API settings apply “when the Data API is enabled for this type.” If the API is off for a type, the type does not answer these calls. Privacy rules still apply to the data inside the app.

Check 4: Use Run as

Bubble has a “Run as” feature. Its glossary describes it as a way to “preview your app as a specific user.” Use it to open each page as a normal user and as a user from a different company. Look for data that the user must not see.

How do I fix it now? Steps in order of urgency

Do these steps in order. Steps 1 and 2 close the largest holes first.

Caution: A new privacy rule can break pages that read data without a login. After you add a rule, a page that worked before can show an empty list. This is the correct result for private data. Then fix the page, and do not remove the rule.

1. List the types that hold private data. Include users, orders, messages, files, invoices, and any type with email addresses or payment details. Start with the types that hold the most private data.
2. Clear the Everyone else rule. Open the automatically created Everyone else rule for the type. Uncheck all boxes: find in searches, view fields, auto-binding, and all API permissions. The Bubble privacy article describes this rule as the one that applies to users that no other rule matches. Its shopping cart example unchecks all of its boxes.
3. Add a rule for the owner. Create a rule with a condition that matches the owner of the record. For an order type, the condition is This Order's Creator is Current User. Give this rule only the permissions that the owner needs.
4. Add a rule for each other role that needs access. Use one rule per role. For example, add a rule for staff with the condition Current User's role is Staff. Do not give a role permissions that it does not use.
5. Choose fields, not “all fields”. Check View all fields only when every field is safe for that role. The Bubble article says this box means “view all fields” and controls viewing only. If you uncheck it, you can choose which fields the role can view. Hide fields such as email, phone, and internal notes from roles that do not need them.
6. Turn off Find this in searches for private types. The Bubble article says that this setting “applies to Do a search for specifically”. The manual says that, if you uncheck it, users in the rule cannot see search results for that type. Turn it on only for the roles that need to search.
7. Close the Data API for types that do not need it. If you do not use the Data API for a type, leave it off. If you use it, give each permission only to the roles that need it. The Bubble article states that searches through the Data API always need explicit permission.
8. Set search privacy to Strict. The Security Dashboard recommends Strict. It flags branches that use Automatic or Off.
9. Remove constraints on sensitive fields. The Bubble issue article warns that repeated searches can still reveal hidden values. In the privacy rule, turn off the search constraint for each sensitive field.
10. Test again with Run as and the logged-out checks. Repeat each check from the confirm section. Do not skip this step.

Warning: Do not add a rule that gives public access to a type “to make the page work”. Fix the page so that it asks for only the data that the user may see.

What a safe rule set looks like

Use this set as a model for a type that holds user-owned records.

How do I fix the other places where Bubble data leaks?

Privacy rules protect the database. Other settings can still leak data. Check these items in the same session.

1. Hide the Swagger documentation. The Bubble issue article says that the Swagger issue triggers when the Data API or Workflow API is on and the Swagger documentation is not hidden. Hide it in the API settings.
2. Delete unused API tokens. The Bubble issue article says that a Bubble API token “grants the bearer full administrative access to your app.” Delete each token that you do not use. Create a new token if a token was shared in a chat or a document.
3. Protect backend workflows. The Security Dashboard flags API workflows that run without authentication. Add an authentication check to each one.
4. Mark file uploads as private. The dashboard flags uploaders that do not have the option “Make this file private” set. Files in a public uploader can be opened by anyone who has the link.

For a wider checklist for this platform, read the Bubble security guide.

How do I check whether someone read my data?

Bubble does not give a full request log of reads in every plan. Use the data that you have, and assume the worst if the data is thin.

1. Check the date when the type became public. Look at the version history of the app. Find the time when you created the type or removed the last rule.
2. Read the server logs. In the Bubble editor, open the logs and look for calls to the Data API and to your API workflows. Look for calls from unknown IP addresses, and for many calls in a short time.
3. Check the records for changes. If the Data API permissions for modify, delete, or create were on for everyone, look for records that you did not create. Look for new users with admin roles.
4. Check other credentials. If a Bubble API token or another secret was readable, delete it and create a new one.

Note: If you cannot prove that nobody read the data, treat the data as read. Your duty to tell users depends on your region and on the kind of data. Ask a lawyer if the data includes health, payment, or identity details.

How do I keep privacy rules correct over time?

Privacy rules break when you add types or change roles. Use these habits.

1. Add the rules when you create the type. Do not wait. Add the owner rule and clear the Everyone else rule in the same session.
2. Review the rules after each new feature. A feature that adds a field also needs a decision: who can view this field?
3. Test with Run as before each release. Test one user from each role. Test one logged-out visit.
4. Open the Security Dashboard before each release. Fix each new issue before you deploy to the live version. Do not ignore a warning because the page looks fine.
5. Use the owner pattern. Store the owner of each record in a field, and use that field in the rule condition. For the general theory, read authorization patterns.
6. Scan the deployed app. The dashboard reads your settings. A scan reads what the live app returns. Both views find different problems.

When should I get help?

Get help in these cases:

• The Data API or the logs show reads from unknown sources, and the data includes personal details.
• You cannot tell which roles need which data, because the app grew without a plan.
• A privacy rule change breaks key pages, and you cannot fix the page logic.
• Your app holds health, payment, or identity data, and you have a legal duty to report a breach.
• You find a Bubble API token in a public place. Delete the token first, then ask for a review.

After the fix, open the app in a private window and run the logged-out checks once more. Then use Run as for each role. Each role must see only its own data.