Job bubble-app-privacy-rule-shows-wrong-records · revised 11 October 2026
Fix a Bubble privacy rule that shows users records that are not theirs
On a Bubble development version, each test user sees only the records your rule allows and a logged-out visitor sees none, checked on the page and by a direct data search.
You might be seeing
- A signed-in user can see records created by other users
- A page that should list a user's own records is empty after a rule change
- The app looks correct because elements are hidden, but a search still returns everything
No passwords, keys, card details or admin invites needed to start.
What usually happened
In Bubble, data reaches the browser unless a privacy rule on the data type stops it, so hiding elements or filtering a list on the page protects nothing. A rule that is missing, too loose or conditioned on the wrong field delivers other users' records, and a rule that is too strict blanks pages that depended on fields the user can no longer see.
Who it’s for: Owner of a Bubble app, built without a developer, who has found that one user can see another user's records or that a page shows nothing for the right user.
Usually starts when: A customer reports seeing someone else's orders, notes or documents, or a change to a rule made the right people see an empty page.
The result: On a development version, a logged-out visitor finds none of the records in the app's pages or searches, each signed-in test user finds exactly their own, and the pages that use the data still work for each persona.
Check whether this job fits
Answer these without sending logins or customer records. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Search as a stranger
On a development version, log in as a dummy user who owns nothing and open the page that lists the data. Then log out and open it again.
Look for: Any record you can see that you should not is data the server delivered to the browser; a privacy rule is the fix, not hiding the element.
What you get
- The corrected privacy rules, named and described in plain language
- A persona by record matrix showing what each can find and see
- A note of anything left public on purpose and any rule that needs a data-model change
Included
- One data type and up to six fields in one Bubble app, on a development version
- Writing or correcting its privacy rules for owner, other signed-in users and logged-out visitors, and an admin role if you have one
- Testing with at least three personas on the page and by a direct search for the data type
- Repairing up to three pages whose conditions break because a field is no longer visible to some users
Not included
- A review of every data type in the app or any security certification
- Data API and API workflow settings beyond what the one type needs
- Legal privacy advice, deletion requests or regulatory compliance work
- Restructuring the data model, or cleaning up values left in deleted fields
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A logged-out visitor's search for the data type returns zero records on the development version; the app's Data API is not part of this test.
Evidence: A screenshot of the search result with count zero.
Test user A finds exactly A's records and test user B finds exactly B's, with none of the other's visible on any page or search.
Evidence: The persona by record matrix with record counts for each.
Bubble's privacy rules checker run on the changed version lists no exposed field for this type, or only fields you have confirmed are public on purpose.
Evidence: A screenshot of the checker result and your written list of intended-public fields.
Each page that uses the data type loads and shows the right records for each persona, with no unexplained empty state.
Evidence: Screenshots of each page for each persona.
Sign-off. You log in as each dummy persona on the development version, see the results and sign off before payment. Your account holder deploys to live.
If it fails. If the agreed checks fail, you do not pay for this fixed scope. We hand over the findings and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- There is a Bubble development version and you can create three dummy accounts with sample records
- You can state in plain words who should see which records
- The data type holds enough sample data for the privacy rules checker to be meaningful
- The app is on a Bubble plan that supports collaborators, with a free collaborator slot (Bubble's Growth plan allows two collaborators, counting the owner)
We stop and tell you if
- Access depends on a relationship more than one step away from the current user, which Bubble's search rules do not support without restructuring the data
- Real customer records are needed to reproduce the fault
- Nobody can decide who is allowed to see the records
- The app's plan does not allow a collaborator and you will not change it
What could go wrong
The previous privacy rules are recorded in the handover, so they can be restored on the development version. The live app is changed only when your account holder deploys.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Tightening a rule breaks a page that depended on a hidden field. | The three-persona test includes every page that uses the type, and up to three affected pages are repaired in scope. |
| A rule fixes the page but a direct data request still returns records. | Acceptance includes a direct search for the type, and the checker is run after the change. |
| Records already exposed cannot be un-seen. | We say plainly that this fixes access from now on; anything about past exposure is your decision and your advice to take. |
An independent reviewer checks the redacted before and after evidence, the list of changes and the way back, and looks separately at anything that touches customer data, payments or logins, before you see the result.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the data type, the access rule in words and the three personas
- Reproduce the leak on the development version and record what each persona can find
- Write or correct the privacy rules and review the find, view, search-constraint and auto-binding settings for each field
- Re-test all personas on the pages and by a direct search, and run the privacy rules checker
- Repair pages that break because a field is now hidden, then have a separate reviewer re-run the matrix
- Hand over the rules, the matrix and the steps to put the previous rules back; your account holder deploys to live
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Builder plan, app, domain and payment-provider charges are yours and are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If other data types need the same check, each is quoted as a separate job. A regular check after app changes can be discussed as a separate service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Bubble's own privacy rules checker lists fields that anyone can see and costs nothing to run; it reports but does not fix. manual.bubble.io
- If a developer already maintains the app, ask them to run this exact persona test on a development version first.
Questions
Is hiding a field on the page enough?
No. Data the server sends to the browser can be read even if it is hidden. Only a privacy rule on the data type stops it from being sent.
Can you tell me whether anyone already saw the records?
No. This job fixes access from now on. Questions about past exposure are for your own advice.
Is this a security audit?
No. It covers one data type and its pages. It is not a review of the whole app and not a certification.
Does a pass mean nobody can read these records any other way?
No. The tests cover the app's pages and its searches. Access through the app's Data API and API workflows is outside this job, so a pass says nothing about them.
Send an enquiry
Send us
- The name of the data type and, in words, who should see which of its records
- Screenshots with real names removed of the page showing wrong records and of the data type's privacy tab
- Whether the app has an admin role and whether anyone uses the app's data API
Later, once you agree
- A Bubble collaborator invitation to the one app with the settings named in the access section (including Only Development), created by you and removable at any time
- Three dummy accounts and a dozen sample records you create, with no real customer data
- A named person who can say yes or no to each access rule
You keep the live site, the builder account, the domain and all customer data. Access is agreed with you in writing before any work starts, and no work starts until it is. Any access we use is through a company-controlled account, never a personal login. Access is a Bubble collaborator invitation to your one app. Bubble needs the collaborator to hold a registered Bubble account, and says its Free and Starter plans do not support collaborators. We ask for the lowest settings that let us edit the app and test as each persona: App set to View and edit, Data set to View and run as (Bubble's run-as feature), Logs set to No access, and the Only Development option ticked, so we can reach only the development version of the app and its database. If testing needs more than that, the quote names it before you invite anyone. We do not ask for the Admin permission, which Bubble describes as the most extensive set of privileges just below the owner level. You create the dummy accounts and sample records in the development version, so no live customer data is needed. We name the exact role and any seat or plan charge in the quote before you invite anyone; those charges are yours. You can remove our access at any time. No passwords or payment details go by ordinary email, and your authorised account holder publishes the final change.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “bubble-app-privacy-rule-shows-wrong-records” as the subject.