HOW TO SECURE BUBBLE - SECURITY GUIDE | VIBEEVAL

Bubble Security Context

Bubble is a no-code platform where the security model lives in two places nobody looks: the Privacy Rules tab on each data type, and the API workflow “expose as public endpoint” toggle. Both default to permissive in new apps. The recurring shape: app works in Bubble’s editor (which always runs as the dev user with full access), then ships, then a curious user discovers the API is open and pulls every record.

Security Checklist

1. Configure Privacy Rules on every data type (Critical)

Data → Data Types → [type] → Privacy. Add a rule like “When Current User’s email is This [Type]’s Creator’s email” with read/write/find/modify locked. Without a Privacy Rule, any logged-in user can search every record of that type via the public API. The Privacy tab being empty is the Bubble equivalent of a Supabase table with RLS off.

2. Audit API workflow exposure (Critical)

Settings → API → API Workflows: every workflow with “Expose as a public API workflow” checked is reachable from the internet. For each: confirm it has authentication (use the “This workflow can be run without authentication” toggle deliberately, not by default), and that the action chain doesn’t trust unvalidated input.

3. Lock down the Data API

Settings → API → Enable Data API: only enable for data types you mean to expose. For each enabled type, configure the per-operation toggles (GET, POST, PATCH, DELETE) — not all four. The Data API respects Privacy Rules, but only if the rules are set; without rules, the API returns everything.

4. Audit installed plugins

Plugins → Installed: every plugin runs JavaScript in your app with full access to the page state. Remove any you don’t actively use. For ones you keep: read the plugin’s source / docs and confirm the permissions it asks for. Plugins from unverified authors can exfiltrate user data; the Plugin Marketplace doesn’t sandbox.

5. Configure user authentication

Settings → General: set minimum password length 8+, enable “Require email verification” for sign-up, disable “Allow signups” if your app is invite-only. Under Workflows → Account → Email reset password: confirm the reset link expiry is short (≤ 1 hour) and the link is single-use.

6. Review hidden visual builder settings

Under Settings → SEO/metatags: check “Make this app private” if it’s not yet ready for crawlers. Under Settings → Versions: confirm the development version isn’t accessible at a guessable URL like appname-bubble.io/version-test — that exposes work-in-progress features and possibly a less-secured rule set.

7. Verify HTTPS everywhere

Bubble apps are HTTPS by default on the bubbleapps.io subdomain. For custom domains: Settings → Domain/Email → Custom Domain, confirm “SSL is active” and “Force HTTPS” are both on.

8. Audit data type field visibility

In Data → Data Types → [type]: every field has a “Privacy” sub-rule. A user-public type may have a password_reset_token or internal_notes field that should not be returned. Configure the visible-field list per Privacy Rule.

9. Configure API authentication for callers

If external services call your Bubble API: use a generated API token (Settings → API → Generate) and treat it as a secret on the caller side. Don’t reuse the token across multiple callers — one rotation breaks everything. Don’t put the token in any client-side code.

10. Test conditional visibility for security boundaries

A Bubble element with a “Conditional → This element is visible when [Current User is admin]” rule hides the element but does not protect the data. The data still loads from the database. For sensitive elements: gate the data source, not just the visibility.

11. Configure email settings

Settings → Domain/Email: set up SPF and DKIM for your sending domain so password reset and verification emails don’t go to spam. Audit your email templates for: links that aren’t on your domain, links that include the user’s session in the URL.

12. Review payment integration

If using the Stripe plugin or Bubble’s built-in payments: handle payment success in a server-side workflow triggered by the Stripe webhook, not in the client-side “after Stripe charge” event. The client event can be skipped — the webhook can’t. See Stripe webhook and paid-trust.

13. Configure server logs

Logs → Server logs: review weekly for anomalous access. Look for: bulk reads of a single data type from a single user, repeated 401s, requests to API workflows you don’t recognize.

14. Manage app versions safely

Versions → Live / Development: deploy to live only after testing in development. The dev version often has different (looser) Privacy Rules; pushing data structure changes without re-checking Privacy on the live version is the most common Bubble incident shape.

15. Audit collaborator access

Settings → Collaboration: every collaborator has full app access by default. Review the list quarterly; remove ex-team members. Use “Application Editor” (read/write app) vs “Domain Manager” (deploy only) carefully.

16. Test with multiple user roles

Create test accounts for each user role you support (admin, paid, free, etc.). Log in as each, try to: view another role’s pages, hit another role’s API workflows, query data the role shouldn’t see. The Privacy Rules tell you what should happen; the test tells you what does.

17. Run a security scan

The Vibe Code Scanner covers the public-surface checks; the full VibeEval scan adds BOLA-style probing across roles and Data API enumeration.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

Automate Your Security Checks

VibeEval scans your Bubble app’s exposed API and Data endpoints, looking for missing Privacy Rules and over-exposed workflows.