Is Bubble Safe? What Privacy Rules Actually Protect · and What They Don't

Quick answer: Yes, Bubble is safe · it is a SOC 2 compliant platform with professional infrastructure. However, security is opt-in. Without manually configured Privacy Rules, your Data API and client-side searches can expose your entire database. You must also mark API Connector keys as private to prevent them from leaking in browser traffic.

By Daniel A · Kraftwire Software

Yes, Bubble is safe · it is a mature, SOC 2 Type II compliant platform with professional-grade infrastructure. However, security is opt-in: without manually configured Privacy Rules, the Data API and client-side searches can expose your entire database to the public. To be safe, you must define a Privacy Rule for every data type and mark all API Connector keys as private.

Key Takeaway

Bubble is inherently safe at the infrastructure level, but it follows a shared responsibility model. While Bubble secures the server and the editor, you are responsible for securing the data. In Bubble, if you do not explicitly create Privacy Rules for a data type, that data is public by default.

What Exactly Is Bubble?

Bubble is a visual programming platform that allows users to build full-stack web applications without writing code. It provides the database, the server logic (workflows), and the frontend hosting in one package.

Because it has been around for over a decade, its security model is well-documented. However, its "ease of use" can be a double-edged sword. A developer can build a functional app in hours, but if they skip the vibe coding security checklist, they may inadvertently leave the "back door" open to their database.

Is Bubble Safe? The Infrastructure vs. The App

When asking "Is Bubble safe?", you must distinguish between the platform and your specific implementation:

• Bubble the Platform · The underlying AWS infrastructure, SSL/TLS encryption, and the Bubble editor itself are highly secure. Bubble undergoes regular penetration testing and maintains compliance standards that most startups couldn't achieve on their own.
• Your Bubble App · This is where the risk lies. If you haven't configured RLS (Row Level Security) via Privacy Rules, your app is not safe.

1. What Privacy Rules Actually Protect

Privacy Rules are the single most important security feature in Bubble. They act as a firewall between your database and the user's browser. As noted in expert discussions, "Privacy rules live in the database, not your design tab" · meaning you cannot rely on visual elements to hide data.

The Data API Risk

If you enable the Data API in your settings but fail to set Privacy Rules, your entire database is accessible via a simple URL. An attacker doesn't need to use your app's interface; they can simply query your API and download every record in a JSON format.

Client-Side Search Exposure

Bubble's "Do a search for" logic often happens on the client side. If a user searches for "Products," Bubble may send the entire list of products to the browser, and the browser then filters them. Without Privacy Rules, even if your UI only shows the product name, the browser might receive the cost price, supplier details, and internal notes.

How to Fix It

• Navigate to Data > Privacy for every single data type.
• Create a rule (e.g., "This User is Logged In" or "This User is the Owner").
• Uncheck "View all fields" for the "Everyone else" (default) rule.
• Specifically select which fields are visible to which roles.

2. API Connector Secrets: The Hidden Leak

The API Connector is how Bubble apps talk to OpenAI, Stripe, or Xano. Each header or parameter has a "Private" checkbox. If this is unchecked, Bubble sends that key from the user's browser. This means anyone can open the browser's "Network" tab and steal your API keys.

If you leak an OpenAI key, an attacker can run up thousands of dollars in charges on your account.

How to Fix It

• Always check the Private box for any secret key or Bearer token.
• If you accidentally exposed a key, rotate it immediately. Deleting the call in Bubble does not invalidate the key on the provider's side.
• Use environment variables security best practices to manage different keys for development and production.

3. Backend Workflows and Public Endpoints

Backend workflows (API Workflows) allow you to run logic on the server. However, they can be set to "Exposed as a public API endpoint." If you check this box and also check "This workflow can be run without authentication," you have created a public URL that can trigger actions in your database.

If that workflow deletes a user or changes a price, anyone who finds the URL can trigger it. Unlike standard workflows, backend workflows don't always respect the "Current User" unless you explicitly pass authentication headers.

How to Fix It

• Never allow unauthenticated runs for workflows that modify data.
• Use "Only when" conditions on the workflow itself to verify the caller's identity or role.
• Disable the Workflow API in Settings > API if you aren't actively using it.

4. Conditionals vs. Security: The UI Trap

A common mistake is using "Element is visible" or "Conditional" tabs to hide sensitive information. For example, hiding a "Delete" button from non-admins does not stop a non-admin from sending a "Delete" command to the server if they know how to use the console.

As experts warn, privacy rules are meant "to show specific results to verified users" at the database level, not just the visual level. If the data reaches the browser, it is no longer private.

How to Fix It

• Use broken access control checklists to ensure that permissions are enforced on the server (Privacy Rules and Workflow conditions), not just the frontend.
• Treat your frontend as a "presentation layer" only. Assume the user can see everything you send to the browser.

5.

For example, the California Opt Me Out Act (AB 566) now requires browsers to include features that tell websites not to share personal information. If your Bubble app handles California residents' data, you must ensure your GDPR/compliance signals are up to date.

Bubble provides the tools for compliance, but it doesn't automate them.

6. Performance and Architecture Risks

Security and speed are often linked. Large, unfiltered searches that lack Privacy Rules not only leak data but also slow down your app as the browser struggles to process thousands of records it shouldn't have received in the first place.

A common architectural flaw in Bubble is "Data Type Bloat" · putting 50 fields on a single "User" type. Because Bubble fetches the whole record, this slows down the app and increases the surface area for data leaks.

How to Fix It

• Use "Satellite Types": Move sensitive or heavy data (like user settings or private logs) to a separate data type linked by a unique ID.
• Follow the performance security guide to optimize your app for both speed and safety.

How to Verify Your Bubble Security

Before you launch, you must move beyond "vibes" and use objective testing.

• The Incognito Test: Open your app in an incognito window without logging in. Open the browser DevTools (F12), go to the Network tab, and refresh. Look for msearch or init calls. If you see data there that shouldn't be public, your Privacy Rules are failing.
• The Two-User Test: Log in as User A and try to access a URL or data point belonging to User B.
• Automated Scanning: Use a Bubble-specific scanner to detect common misconfigurations. SimplyScan's free tool checks for exposed API keys, missing headers, and common XSS or CSRF vulnerabilities in ~30 seconds.

Running a production app? Consider Pro Monitoring to get alerted the moment a configuration change accidentally exposes your data or slows down your site.

FAQ

What are privacy rules in Bubble?

Privacy Rules are Bubble's version of Row Level Security (RLS). They define who can find, view, and modify specific data types at the database level. Unlike UI conditions, Privacy Rules stop data from ever leaving the server if the user doesn't meet the criteria. They are opt-in, meaning every new data type is public until you create a rule for it.

Can someone download my entire Bubble database?

Yes, if the Data API is enabled and you have not configured Privacy Rules for your data types. An attacker can use the Data API endpoints to fetch every record in your database as a JSON file. To prevent this, ensure every data type has a "default" rule that prevents "Everyone else" from finding or viewing data.

Are Bubble search constraints enough to protect data?

No. Search constraints (the "constraints" section of a "Do a search for" expression) are filters, not security. They tell the browser what to show, but the server may still send the full data set to the browser. Only Privacy Rules provide true security by preventing the data from being sent to the client in the first place.

Is it safe to put API keys in Bubble's API Connector?

It is only safe if you check the "Private" box for each key. When a key is marked private, Bubble handles the API call on its own servers, keeping the key hidden. If the box is unchecked, the key is sent to the user's browser, where it can be stolen via the Network tab.

Do I need privacy rules if my Bubble app data is public anyway?

Even if your content is public (like a blog), you should still use Privacy Rules to protect internal fields like "Owner Email," "Internal Notes," or "Draft Status." Additionally, rules prevent unauthorized users from modifying or deleting your public content. A "read-only" public rule is safer than no rule at all.

How do I test my Bubble app's security before launch?

Start by using the "Run as" feature in the Bubble editor to test different user roles. Then, use a tool like SimplyScan to check for exposed secrets and security headers. Finally, perform a manual audit of your Network tab to ensure no sensitive fields are being leaked in search results or API calls.