Bubble app security: privacy rules, Data API and workflow API checklist

Bubble apps keep their data on Bubble's servers, and the browser asks for it. Privacy rules decide what the server sends back. If a data type has no privacy rules, treat it as readable by anyone who can reach the app.

This guide has a test checklist for your own Bubble app and a sample privacy-rule design. Test only apps you own or have written permission to test.

How do Bubble privacy rules work?#

Privacy rules are conditions you set on each data type. They run on the server. Bubble's docs say they tell the server "to only send data to the browser, or write to the database, if certain conditions are met."

Four behaviors cause most mistakes:

• Rules grant, they do not deny. Bubble says: "you don't prohibit access, you grant it." Every rule a user matches adds its permissions, and they stack up.
• "Everyone else" is a rule too. The editor adds an automatic rule for everyone else. If its boxes are ticked, every visitor gets those rights. Clear them unless the data is public.
• Field permissions are narrow. "View all fields" means view. Bubble states it "doesn't stop someone from making changes to the field in a workflow."
• Search is a separate switch. "Find in searches" applies to Do a search for. The record can still be fetched in other ways. A search in a workflow returns only data the current user can access.

The editor marks each type as having privacy rules applied or as publicly visible. Sensitive data, Bubble says, needs privacy rules to count as secure.

What does the Bubble security checklist say?#

Bubble's own checklist has items that testers verify:

• "Add privacy rules to all private data types."
• Use "Only when" conditions to protect data from unauthorized editing in workflows, or use auto-binding with privacy rules.
• Bubble's JavaScript files expose details such as names and attributes of option sets, and information stored in the API Connector.

Anything in an option set or a client-side API Connector field is visible to a visitor who reads the page's JavaScript, so keep keys and private logic out of both.

How do you test a Bubble app? A checklist#

Use two normal users, A and B, a logged-out browser, and (if you use the APIs) the API tokens you issued.

1. Inventory the data types.#

• List every data type in the editor's Data tab.
• Mark each as public, per-user, per-team or admin only.
• Open each type's Privacy tab. Note any type shown as publicly visible.

2. Review each rule set.#

• The "Everyone else" rule has no boxes ticked, unless the type is public.
• Each rule's condition names the right owner or role field, not just "is logged in".
• Sensitive fields (email, phone, address, tokens, notes) have View permission only where needed.
• "Find in searches" is off for private types, or is limited by the same condition.
• Rules do not rely on chained references deeper than one level for search access. Bubble says those cannot grant search access.

3. Test from the browser.#

• Log out and open pages that show data. Watch the network tab for responses that hold more fields than the page shows.
• As user B, load a page that shows A's record by its URL parameter or ID.
• As user B, try edit and delete workflows on A's record. Read the record back as A to check the result.
• Check auto-bound inputs. Auto-binding rules do not stop the same change in a workflow.

See IDOR testing and multi-tenant isolation testing for the two-account method.

4. Review the Data API.#

• Open Settings, API. List the data types set as active in the Data API. Bubble says a type must be active to be reachable.
• For each active type, review the Create via API, Modify via API and Delete via API permissions in its privacy rules.
• Confirm the changes are deployed to the live version. Bubble notes settings must be deployed.
• Call each active type with no token, with user A's token and with user B's token. Compare results to what each should see.
• Note that PUT clears fields you do not send. Use PATCH for partial edits on test data.

5. Review the Workflow API and backend workflows.#

• List workflows marked as public API workflows. Private ones are not callable from outside the editor.
• Check each authentication level. Bubble says "None required" lets any client trigger the workflow and "can make the workflow vulnerable to misuse." Use it only for sign-up and login.
• "User & admin" lets any authenticated user run the workflow. Limit it with conditions and privacy rules.
• For each workflow with Ignore privacy rules set, read the steps. It runs as an admin with all rights to the data. Test what a normal user or a logged-out caller can pass in.
• Check parameters. A workflow that takes a record ID from the caller needs a check that the caller owns it.

6. Review client-visible data.#

• Search the page source and JavaScript for keys, tokens, and private option set values.
• Review the API Connector. Bubble's checklist lists its stored information as visible in client JavaScript, so check Bubble's docs for which fields stay server-side.

What does a safe privacy-rule design look like?#

This design is for a Projects data type in an example app. Adapt it.

Rules for the design:

1. Start with "Everyone else" empty, then add rules that grant access.
2. Add "Only when" conditions to editing workflows, so a user cannot change records they do not own.
3. Put private fields, such as internal notes, in a separate data type with a stricter rule.
4. Do not store secrets in option sets. Use a server-side mechanism for keys.
5. Re-test after every privacy-rule change.

What are the common Bubble mistakes?#

Common flaws in Bubble apps:

• A data type with no privacy rules. New types start open until you add rules.
• "Everyone else" left with View ticked. Every visitor can read the type.
• Search open on private types. Find in searches lets any user list records.
• Edit workflows without "Only when". Any user who can trigger the workflow can change any record it touches.
• Backend workflows set to None required. A workflow meant for sign-up also changes user data.
• Ignore privacy rules left on. A convenience setting turns into admin access.
• Secrets in option sets or page elements. They ship to every browser.
• Test data in the live app. Old test types hold real-looking records and weak rules.

Each flaw has a test in the checklist above. After each fix, repeat the test with the same two accounts.

How should you document the test?#

Keep a table with one row per data type. Columns: type name, who should see it, Everyone-else permissions, search setting, Data API status, result of the logged-out test, result of the second-user test. The table is your evidence and your regression list. Re-run it after each release that adds a data type or changes a rule.

What do testers report?#

A good finding states the data type, the caller, the request and the proof. For example: "A logged-out caller reads Invoice records through the Data API. Cause: Everyone else has Find in searches ticked. Fix: clear the box and add an owner rule. Retest: logged-out call returns no records." Include a read-back from the owning account for writes.

For risks across Bubble, Supabase and Firebase, see no-code app security testing. For the database-first view, see Supabase security testing.