Bubble security guide: privacy rules, APIs and files

By Thunkle · Platform references checked 19 September 2026

Bubble privacy rules need to match your application's roles and data, not just satisfy a checklist. A customer, a staff member and an anonymous visitor may all need different access to the same data type. The review starts with those requirements.

It is also important not to overstate the risk: Bubble's Data API is configurable. Do not assume every app exposes every data type, or that every publicly readable record is unintended. Our Bubble security audit establishes the actual scope before testing.

Have a developer connect privacy rules to workflows

In Bubble, the important review often spans visual configuration rather than a conventional source repository. A developer should follow privacy rules, enabled APIs, plugins and backend workflows as one system, then test the same operation as different users. This helps establish whether a workflow exposes or changes data that the visible page correctly hides.

Our paid Bubble security audit is a developer-led audit of the agreed configuration and workflows, with findings you can act on inside your app. Deliverables include supporting evidence and remediation guidance, plus a free re-review of agreed fixes. Implementation is a separate scope.

Inventory the enabled entry points

List the data types exposed through your enabled Data API, the API workflows your app uses and the files attached to private records. Include plugins and third-party services that operate with elevated access.

Bubble documents separate Data API read and mutation controls. It also distinguishes user authentication from an administrative API token, which bypasses privacy rules. Testing with an administrative token cannot establish what an ordinary customer is allowed to do. Bubble Data API privacy rules.

Keep administrative credentials out of the browser, plugins or integrations that do not need them. Record which path uses which identity, without copying token values into a report or quote form.

Translate privacy rules into customer outcomes

Use a synthetic booking portal as a test model. A customer may see their booking date and public venue information. Staff may need the customer's contact details. Internal dispute notes should not reach the customer simply because they share a booking record.

Review the fields returned to each actor and whether searches reveal records outside that actor's scope. A list hidden by interface conditions is not enough evidence. Check the backend response using dedicated accounts and synthetic records in an authorized test environment.

Preserve a successful allowed request for each account. Otherwise an invalid session or missing booking can look like a correctly denied request. Our two-account experiment explains the method, though its Supabase-specific checker is not a Bubble testing tool.

Review workflows separately from Data API settings

Do not assume the Data API's create, modify and delete controls govern every backend workflow. Review the workflow's own authentication, inputs, conditions and privilege settings.

For a cancellation workflow, establish who may cancel which booking, whether cancellation is allowed at that stage, and what external effects follow. An authenticated caller should not gain authority merely by supplying another customer's booking identifier.

In isolated tests, check both the response and the resulting stored state. A rejected cancellation must not still trigger a refund, email or background action. Use test-mode payment providers and an email sink, not customer accounts or live transactions.

Follow private files beyond the record

A file reference in a private record does not, on its own, prove that the download is private. Review how the file is uploaded, attached and served, and the relevant file-view permissions. Test the actual URL with the intended accounts and a signed-out browser.

Decide what should happen when a record is reassigned or access is revoked. Check existing links as well as newly generated ones. Public marketing images and private customer documents should not be assigned the same sharing expectations merely because both are uploads.

Keep a launch acceptance record

• Record which Data API types and workflows are enabled.
• Identify normal-user versus privileged integration credentials.
• Verify allowed reads and forbidden cross-customer reads.
• Check restricted fields in the actual response.
• Test writes and workflow side effects with disposable data.
• Test private downloads and access revocation.

Run the platform's available security checks and investigate their findings. Automated tools can catch real problems; the remaining review question is whether the configured behaviour matches your product. Our Bubble dashboard article discusses that distinction.

Does a Bubble app need to migrate to become secure?

Not necessarily. Correcting privacy rules, workflow conditions or integration access can be the appropriate fix. Migration is a separate architectural decision.

When should I get an audit?

When customer records, private files, payments or complex roles make an incorrect permission consequential. No audit can guarantee the absence of all vulnerabilities.

Get a security audit quote. We agree scope and authorized actions before testing, then deliver prioritized evidence and remediation guidance. Fix implementation can be scoped separately, with a free re-review of agreed fixes.