Is Bubble Safe? What Privacy Rules Actually Protect · and What They Don't
Bubble is the most mature no-code platform around, but privacy rules are opt-in. Skip them and your entire database is one API call away.
By Daniel A · Kraftwire Software
· 6 min readKey Takeaway
Yes, Bubble is safe · it is the most mature no-code platform in the market, and its infrastructure is not your problem. Your problem is that privacy rules are opt-in per data type: skip them and the Data API plus client-side searches will hand over entire tables to anyone who asks. Set privacy rules correctly and Bubble apps can be genuinely secure.
What Bubble Actually Is
Bubble is a visual full-stack builder that predates the AI wave by a decade. You design pages, define data types, and wire logic with workflows · no code, but a real database and a real API underneath. Thousands of production businesses run on it, which means its security model is well understood. That is good news and bad news: the sharp edges are documented, and attackers have read the documentation too.
Bubble's core design choice is the one to internalize: security is opt-in. A fresh data type has no privacy rules, and no privacy rules means everyone can find every record and read every field. Nothing warns you loudly about this. The app works perfectly either way · that is exactly what makes it dangerous, and it is the pattern we cover across no-code platform security in general.
The Short Answer: Yes · With Conditions
- Bubble the platform · hosting, TLS, the editor, their infrastructure. Mature, professionally run, audited. Not where your risk lives.
- Your app's privacy rules, API settings, and workflows · entirely on you, and by default more open than most builders' defaults.
Here are the vulnerability classes that actually bite Bubble apps.
1. Missing Privacy Rules · the Whole-Table Problem
Privacy rules are Bubble's row-and-field-level security, and they must be created per data type. Without them, two doors stand open:
- The Data API. If it is enabled for a type with no privacy rules, anyone can request every record over plain HTTP, no login required.
- Client-side searches. Bubble evaluates "Do a search for" partly in the browser. Without privacy rules constraining what leaves the server, far more data ships to the client than your page displays. Search constraints are filters, not security.
The result is the classic Bubble breach: an app that looks fine, driven by a database anyone can dump.
How to fix it
- Open Data → Privacy and create a rule for every data type. No exceptions, including types you consider boring.
- Default to deny. Start from "This User's thing" patterns · a user can find and view records where
Created by = Current User · and widen only deliberately.
- Tick field visibility consciously. A rule that lets everyone find records and view all fields is barely better than no rule.
- Re-test after every new data type. Privacy rules do not inherit; each new type is born open.
Our Bubble security guide has a step-by-step privacy-rule walkthrough with the common patterns.
2. API Connector Keys Visible in Network Traffic
The API Connector is how Bubble apps call external services, and every credential field has a "private" checkbox. Keys not marked private are sent from the browser, which means they appear in plain sight in the Network tab. Users have shipped Stripe, OpenAI, and SendGrid keys this way without ever pasting them into "code."
How to fix it
- Open every API Connector call and confirm each key field is marked private, which forces the call server-side.
- Prefer initializing calls as server-side actions in workflows over page-loaded data calls when secrets are involved.
- If a key was ever exposed, rotate it. Deleting the call does not un-leak the key. Our guide to API keys in frontend code covers which key types are safe in the browser and which never are.
3. Public Backend Workflows
Backend workflows (API workflows) are Bubble's server-side endpoints, and they can be exposed as public API endpoints. A public workflow that creates records, sends emails, or modifies data · without checking who is calling · is an open invitation. Attackers do not need your UI; they need the endpoint name, and endpoint names leak constantly through browser traffic, error messages, and guessable conventions like create_user or delete_item.
The damage compounds because backend workflows run server-side with real authority. A public workflow that deletes a record "the current user owns" deletes whatever record ID the caller supplies, unless you added the ownership check yourself.
How to fix it
- Turn off "This workflow can be run without authentication" unless you have a specific, defended reason.
- Inside the workflow, verify the current user and their role before touching data. "Only when Current User's role is admin" belongs on the workflow, not just the button.
- Audit Settings → API and disable the Workflow API and Data API entirely if you do not use them.
4. Conditionals Mistaken for Security
Hiding an element "when Current User's role is not admin" hides pixels. The page, its searches, and its workflows still exist, and the data still flows to the browser where devtools can read it. The same goes for option sets, which are always fully downloadable by every visitor · never store anything sensitive in one.
How to fix it
- Enforce access in privacy rules and workflow conditions, never only in element visibility.
- Treat everything on a page · including hidden groups and their data sources · as visible to every visitor of that page.
5. Over-Broad Rules and Leaky Workflows
Privacy rules protect data at rest, but a workflow running with elevated access can still copy sensitive values into fields a user can see, write them into logs, or email them to the wrong person. Rules also cannot fix a data model that mixes public and private fields in one type.
How to fix it
- Split data types so sensitive fields live in types with strict rules, referenced from leaner public types.
- Review any workflow that moves data between types: does it launder private data into a visible field?
When NOT to Worry
- Genuinely public data. A directory or blog with open read access is a design choice, not a hole.
- Your app has no user accounts and stores nothing personal. Most of the classes above assume there is something to take.
- Bubble's infrastructure findings. Headers and TLS on
bubbleapps.io are Bubble's layer; focus on the parts you control, and check the rest with our security headers tool once you are on a custom domain.
How to Verify Before You Launch
Do the two-account test: create a second user, then try to search and view the first user's data. Hit your Data API endpoints logged out. Watch the Network tab while browsing and read what actually leaves the server · not what the page displays, but the raw responses underneath it. Repeat the pass on your development version before you deploy, because privacy rules apply per environment snapshot and a rule you added after your last deploy is not protecting live users yet. Then run the sweep · SimplyScan checks 51+ items across 14 categories, the free tier covers secrets, frontend exposure, and speed, and the Bubble scanner page shows exactly what we look for on this platform. For the wider pre-launch routine beyond Bubble specifics, our security audit checklist is the companion piece.
Running a Bubble app with real users? Get a free security scan and see in thirty seconds whether your privacy rules are actually doing their job.