Bubble apps showing the wrong records: why hiding on the page is not protection

Where the data goes

Bubble checks privacy rules on the server. A rule is a condition on a data type, and the server sends or writes data only when the condition passes. That is the whole mechanism, and it has a consequence worth stating plainly: because the check happens before data leaves the server, protection can only come from a rule on the data type. This is our inference from how Bubble describes it, not a Bubble sentence: a page that hides an element or filters a list after the data has arrived has not stopped the data being sent.

In the editor, each data type is labelled either as having privacy rules applied or as publicly visible. A type with no rules is the first place to look when a user sees records that are not theirs.

• Open each data type's privacy tab and read the label.
• Do not trust a filter on a page as a protection.
• Keep a list of the types that hold personal or commercial records.

Settings that surprise people

Several permissions look the same but do different things. Find this in searches applies only to a search for the type; the record can still be reached by other routes. View all fields controls viewing, not changing: it does not stop a workflow making changes to a thing. Allow auto-binding stops changes made through auto-bound elements, not the same change made in a workflow. A user's access is the sum of every rule they match, so access is added up, not subtracted, and an Everyone else rule that grants something adds to whatever a stricter rule allows.

There are also search privacy modes: off, automatic and strict, with strict recommended for sensitive data. Allowing a search constraint on a field that users cannot view can leak its values by inference, because they can test guesses against it.

• Check what the Everyone else rule grants on each type.
• Use strict search privacy for sensitive types.
• Re-test after any change; rules do not refresh on an already open page until it reloads.

Conditions and the one-step limit

You write a rule's condition in the When field, using the current user: whether they are logged in, whether they are the thing's creator, whether an Admin field is yes, or whether they are in a list field on the thing. Bubble notes that a chain of references more than one level deep cannot grant search access, so the data must be restructured so the check reaches only one level, for instance by testing a field on the current user.

When you deliberately need to bypass rules, an API workflow can ignore privacy rules while it runs. That is useful and dangerous in equal measure, so list every workflow that uses it.

• Test the condition with a user who owns nothing.
• Prefer a direct link from the record to its owner.
• List workflows that ignore privacy rules.

A safe two-account test, what does not fit, and acceptance

Make two dummy accounts on a development version, create a record under each, and log in as each in turn, then log out and look again. Run Bubble's privacy rules checker, which flags fields anyone can access; it needs sample data and only reports. Note that values left in a deleted field can still come back through API responses, and a rule on a deleted field is still enforced, so clear sensitive data before deleting a field.

A whole-app review, legal privacy advice and certification are different from this. The fixed-scope fix of one data type is priced at £325 as an untested proposal and paid only after you sign off. It is accepted when a logged-out search returns zero records, each test user finds exactly their own records, the checker lists no unintended exposed field for the type, and every page using it still works for each persona.