BUBBLE SECURITY CHECKLIST

Bubble’s security model centers on Privacy Rules — per-data-type access policies that decide who can read what. The most common Bubble breach pattern is the same as the most common Firestore breach: privacy rules left at “everyone can see all fields” because that was the default that made the demo work. Combined with API Workflows that expose the backend to the public internet (often with no auth), and plugins that bypass privacy rules entirely, Bubble apps frequently ship with their entire database readable. The checklist below is what we look for first when we audit a Bubble app.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once in the Bubble editor for your live app, ticking items as you go. Use Bubble’s “Privacy Rules” simulator to actually test rules against expected attacks (signed-out user reading a private record; user A reading user B’s data). After the whole list passes, run a black-box scan against the live URL to confirm the rules behave the way the simulator says they do.

Critical (fix before launch)

1. Configure privacy rules on every data type

Why it matters. Bubble’s default privacy rule is “Everyone else (default permissions)” with all fields visible. Without explicit per-data-type rules, any user — including unauthenticated — can read every field of every record via Bubble’s Data API or by inspecting the page state in DevTools.

How to check. Data → Privacy → [each data type]. Confirm at least one rule is defined that scopes access by Current User, by role, or by an explicit field condition. The “Everyone else” fallback at the bottom should reveal no fields.

How to fix. Add a rule per role: Logged-in user, Owner, Admin. Set the “Everyone else” fallback to grant zero fields. Test in Privacy Rules debug mode.

2. Lock down API workflow exposure

Why it matters. Bubble’s API Workflows (Backend Workflows) can be exposed publicly via “Expose as a public API workflow” — meaning anyone can call them with a POST request. We routinely audit apps where this is enabled on workflows that update prices, grant roles, or send emails.

How to check. Backend Workflows. For each workflow, check whether “Expose as a public API workflow” is enabled. Confirm each public workflow has explicit authentication (API key check, signed parameter, or “This endpoint can be run without authentication” off).

How to fix. Disable public exposure on workflows that don’t need it. For workflows that genuinely need to be public, verify auth at the start of the workflow.

3. Strip API connector credentials from client-visible workflows

Why it matters. Bubble’s API Connector lets you call third-party APIs. If a workflow that uses the connector runs in the page (rather than in a backend workflow), the request — including any API key in the headers — happens from the user’s browser and is visible in DevTools.

How to check. Audit each API Connector call. Confirm calls that pass authentication headers run only in backend workflows, not in page workflows.

How to fix. Move auth-bearing API calls to backend workflows. Page workflows that need data should call your own backend workflow, which calls the third-party API.

4. Audit option sets and database fields for sensitive default visibility

Why it matters. Privacy rules control field visibility, but option sets and computed fields sometimes leak through. A field “Display name” that’s safe to show globally is fine; a “Stripe customer ID” that’s also visible “to everyone else” by default is a leak.

How to check. Walk every data type’s field list. For each field that contains identifiers, internal IDs, or third-party references, confirm it’s behind a privacy rule that limits visibility.

How to fix. Restrict field visibility per privacy rule. Audit after every schema change.

5. Disable file uploads in fields that don’t need them

Why it matters. Bubble file fields accept any file by default. Without restrictions, users can upload HTML files that get served from your domain and execute as same-origin scripts (stored XSS), or upload malware that gets shared via shared file URLs.

How to check. Audit every file field. Confirm allowed types are restricted to what the field actually needs.

How to fix. Restrict allowed extensions per field. Force Content-Disposition: attachment if Bubble exposes it. For images, use Bubble’s Image fields rather than File fields, which apply some processing.

6. Verify the Data API is disabled or auth-restricted

Why it matters. Bubble’s Data API (/api/1.1/obj/<type>) exposes every record of a data type to anyone with the URL — subject to privacy rules. If privacy rules are weak (item 1), the Data API is the easiest way for an attacker to dump the whole database.

How to check. Settings → API → Data API. Confirm it’s disabled, or confirm every exposed data type’s privacy rules deny access to unauthorized requests.

How to fix. Disable the Data API unless a service genuinely uses it. If you need it on, require API key auth and tighten privacy rules so only the right rows are returned.

High (fix in the first week)

7. Configure app password protection during staging

Bubble apps can be password-protected at the app level during development. Use this on staging and pre-launch sites to keep them out of search engines.

8. Restrict admin pages by user role conditionals

Admin pages should not just hide UI based on a “user is admin” condition — every server-side action on the page must also check the role. Verify admin actions in backend workflows, not just in page workflows.

9. Add CAPTCHA on signup and forms

Use Bubble’s reCAPTCHA element on signup, password reset, and any form that creates database records. Without it, bots create test accounts and spam records.

10. Pin plugin versions

Plugins evolve and sometimes change behavior in ways that affect security. Pin specific versions; audit changelogs before bumping.

11. Verify webhook handlers check signatures

Stripe, Resend, GitHub all sign webhooks. Bubble backend workflows that receive webhooks usually skip signature verification — fix this before payments go live.

12. Disable email enumeration in the auth flow

Bubble’s signup, password reset, and login should return identical responses for “user exists” and “user does not exist.”

Medium (fix when you can)

13. Audit installed plugins for unmaintained code

Plugins live forever even when their authors don’t. Audit periodically; replace unmaintained plugins with native Bubble or maintained alternatives.

14. Restrict editor access by role

Bubble editors can change every part of the app. Audit who has editor / admin / read-only; downgrade where you can.

15. Document privacy rule rationale per data type

Maintain a written record of which roles can read/write each data type and why. When schema changes, you have something to diff against.

16. Set up monitoring for unusual API call patterns

Bubble logs API workflow calls. Ship them somewhere alertable; flag patterns like “single user creates 1000 records in a minute”.

17. Configure security headers via custom code

Bubble lets you add custom HTML/JS in the page header. Use it to set CSP, X-Frame-Options, and similar via meta tags or via your CDN if you front Bubble with one.

18. Restrict who can deploy to live

Bubble’s “Push to live” is the deploy. Restrict to a small group; require change documentation.

After every editor change

• Re-test privacy rules on changed data types.
• Re-confirm public API workflows still need to be public.
• Check for newly added file upload fields.
• Verify no sensitive field was added without privacy rule coverage.

Common attack patterns we see in Bubble apps

The “everyone” privacy rule. Data type left at default; signed-out user iterates the Data API and dumps every record.

The public API workflow. Backend workflow “ChangeUserRole” exposed publicly with no auth check. Anyone can POST to grant themselves admin.

The browser-side API key. API Connector call to Stripe runs in a page workflow; secret key sent from the browser. Visible in DevTools; immediately exploitable.

The plugin that bypassed privacy. Third-party plugin uses Bubble’s internal API to query data, ignores privacy rules. Used in admin dashboard; reachable to non-admins via direct page URL.

Related Resources

How to Secure Bubble

Step-by-step guide for hardening a Bubble app — privacy rule patterns, API workflow auth, plugin auditing, and the role-design above in long form.

Is Bubble Safe?

In-depth analysis of Bubble’s defaults — what privacy rules cover, what they don’t, and what we find when we audit a typical Bubble app.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through your Bubble app, attempts the privacy-rule bypass and public-workflow attacks above, and reports what got through.