Bubble Security Guide: Privacy Rules, API Tokens, and Data Exposure
Bubble apps face unique security challenges from privacy rules, exposed API tokens, and database leaks. Learn how to secure your Bubble.io application.
By Daniel A · Kraftwire Software
· 9 min readBubble is the most popular no-code platform for building web applications. But a community audit of 11,026 Bubble apps revealed alarming security patterns that every Bubble builder needs to understand.
If you are building on Bubble, security is not optional. The platform gives you the tools to build secure apps, but it does not enforce secure defaults. The responsibility falls on you, and the stakes are high when your app handles user data, payments, or sensitive business information.
The Biggest Bubble Security Risks
1. Missing Privacy Rules
Privacy rules are Bubble's equivalent of Row-Level Security. Without them, all data in your database is publicly accessible via the Data API.
This is the number one security mistake in Bubble apps. If you do not explicitly configure privacy rules for a data type, anyone can query it, even without logging in. They do not even need to use your app. They can hit the Bubble Data API directly and pull every record from every unprotected table.
**What makes this so dangerous:** Many Bubble builders assume that if data is not displayed on a page, it is not accessible. That is wrong. The data is accessible through the API regardless of whether it appears in the UI. The only thing that controls API access is privacy rules.
**How to check if you are affected:** Open your browser DevTools, go to the Network tab, and look for requests to your Bubble app's data API. If you can see data from other users or data that should be private, your privacy rules need work.
2. Exposed API Tokens
Bubble API tokens grant full administrative access to your app. A leaked token allows an attacker to:
Override all privacy rules and read every record in your database
Modify or delete any data, including user accounts
Trigger all publicly exposed API workflows
Impersonate any user and perform actions on their behalf
Bubble's secrets scanner (introduced in 2025) helps detect leaked tokens, but it is only available on the Growth plan and above. If you are on the Starter plan, you need to audit for token exposure manually.
**Where tokens commonly get leaked:**
Hardcoded in API Connector configurations that are visible in the debugger
Shared in support forum posts when asking for help
Committed to version control if you export your app or use custom plugins
Passed in URL parameters where they get logged in server and browser history
3. Database Exposure Through Searches
Even with privacy rules in place, data can leak through several channels that builders often overlook:
**Search constraints** can inadvertently expose filtered results. If a search returns data that the current user should not see, privacy rules on the displayed fields may not cover all the information leaked through the search itself.
**Option sets** that contain sensitive configuration values are accessible to all users by default. If you store API endpoints, pricing tiers, or feature flags in option sets, users can read them.
**URL parameters** that reference database IDs allow users to guess or enumerate other records. If your page URL includes a record ID, users can try changing it to access other records.
**Workflow data** passed between pages may be visible in the browser debugger if not properly protected.
**How to test for data leakage:** Use Bubble's debugger in a private/incognito window without logging in. Navigate through your app and watch what data loads in the network requests. If you see data that should be private, you have a leak.
4. Sensitive Data in Workflows
Bubble workflows can expose sensitive data in ways that are not obvious:
Pre-filled form values visible in the Bubble debugger show data that should be server-side only
Workflow action parameters are visible in network requests, so any data passed through a workflow step can be intercepted
Custom states that store sensitive data persist on the client side and can be read through the browser console
Conditional logic that checks against sensitive values (like comparing a user's role to "admin") exposes those values in the debugger
**How to fix it:** Move sensitive operations to backend workflows. Backend workflows run on Bubble's servers, not in the browser, so their internal data is not visible to the user. Use them for any operation that involves sensitive data, role checks, or administrative logic.
5. Unprotected Backend Workflows
Backend workflows (API workflows) that are not properly secured can be called by anyone who discovers the endpoint URL. Without authentication or token verification, these become open backdoors into your application.
**The risk is significant:** Backend workflows often perform privileged operations like creating admin accounts, modifying billing information, processing refunds, or sending bulk emails. If an attacker can call these workflows without authentication, they have administrative access to your app.
**How to discover if your workflows are exposed:** Look at your API workflow settings. If "This workflow can be run without authentication" is checked and there is no token verification in the workflow, anyone who knows or guesses the endpoint URL can trigger it.
6. Insecure Plugin Usage
Bubble's plugin ecosystem is powerful but introduces additional security risks:
Plugins can access your app's data and make external API calls
Plugin code runs in the browser and can be inspected by users
Some plugins store sensitive configuration in client-accessible locations
Plugin updates can introduce new vulnerabilities or change behavior
**How to reduce plugin risk:** Audit every plugin in your app. Remove plugins you no longer use. For critical plugins (payments, auth, data processing), review the plugin's source code if available, or verify that the developer is reputable and actively maintaining the plugin.
How to Secure Your Bubble App
Step 1: Audit Every Data Type
For each data type in your Bubble database:
Go to the Privacy tab in the Data section
Add a privacy rule for every data type that is not intentionally public
Set "When" conditions to control who can see what. For example, "Current User is the Creator" for user-owned data
For sensitive fields (like payment info or private notes), restrict individual field access, not just the whole record
Test by accessing your app as a logged-out user and checking what data is available through the API
Step 2: Protect Your API Tokens
Never share API tokens in client-side code, URLs, or public forum posts
Rotate tokens regularly through Settings, then API, then Regenerate
Use Bubble's built-in secrets scanner if available on your plan
Consider using API workflows with built-in authentication instead of raw API tokens for external integrations
Step 3: Secure Backend Workflows
For every API workflow in your app:
Only enable "This workflow can be run without authentication" when absolutely necessary (like webhook receivers)
Add a secret token parameter to every workflow and validate it before executing any logic
Use Bubble's built-in authentication to restrict access by user role
Log all workflow executions so you can audit who called what and when
Step 4: Lock Down Search Constraints
Never rely on search constraints alone for security. Searches filter results but do not enforce access control.
Always pair searches with privacy rules. Privacy rules are the enforcement mechanism. Search constraints are a convenience feature.
Test by searching as a logged-out user to see what data your API returns
Pay special attention to searches that include "Do a search for all" without filtering by the current user
Step 5: Secure Your Test Environment
Bubble apps have a test version (version-test) that is often left unprotected. This version may contain real user data and is frequently used for debugging, making it a prime target.
Go to Settings, then General, then Application rights
Set a username and password for the test version
Consider restricting access by IP address if your plan supports it
Never share test environment credentials publicly
Step 6: Review Plugin Security
Remove plugins you no longer use
Check each plugin's permissions and data access
Update plugins regularly to get security patches
Prefer plugins from verified developers with active maintenance
Step 7: Scan with SimplyScan
Use [SimplyScan](https://simplyscan.io) to scan your live Bubble app for:
Exposed data endpoints accessible without authentication
Leaked API tokens and secrets in client-side code
Missing security headers
Publicly accessible sensitive data through the Data API
Bubble's Built-In Security Dashboard
Bubble offers a security dashboard with automated checks. What is available depends on your plan:
**Starter**: Missing privacy rules, weak passwords, workflow exposure checks
**Growth**: Database exposure risks, compromised API token detection, unprotected backend workflow scanning
**Team and Enterprise**: Full security suite including advanced scanning and compliance features
If you are on the Starter plan, you are missing critical security checks. SimplyScan fills this gap by scanning your deployed app from the outside, which catches vulnerabilities that internal tools might miss.
Key Takeaways
Privacy rules are mandatory. Without them, your data is public. This is the single most important thing to understand about Bubble security. If you only do one thing from this guide, go to your Data tab and add privacy rules to every data type.
API tokens grant full admin access to your app. Treat them like passwords. Rotate them regularly, never expose them in client-side code, and use backend workflows with authentication instead of raw API tokens wherever possible.
Backend workflows need authentication, not just obscurity. A hidden URL is not a security measure. Add token verification and authentication checks to every backend workflow.
Test as a logged-out user regularly to find exposure. And scan your deployed app with [SimplyScan](https://simplyscan.io) to catch what manual testing misses.
Related Guides
[No-Code Platform Security Guide](/blog/nocode-platform-security)
[FlutterFlow Security Guide](/blog/flutterflow-security-guide)
[WeWeb Security Guide](/blog/weweb-security-guide)
[Xano Security Guide](/blog/xano-security-guide)
[Architecture Security Risks](/blog/architecture-security-risks)