What Bubble's Security Dashboard won't fix for you

Bubble ships a Security Dashboard now. It scans your app, checks your privacy rules, and flags the data types you left open. This is genuinely good, and if you have a Bubble app you should turn it on today. It is also the beginning of the job, not the end, and the difference is worth understanding before you assume a green dashboard means a safe app.

I should say plainly that fixing this is something we sell, so weigh the rest accordingly. The facts underneath it are checkable, which is the point.

The one flaw that matters most

Every Bubble app exposes a Data API. It is how the app's own front end reads and writes the database, and it is public by design. What controls who can read what through it is a set of privacy rules you define per data type. Miss them on a data type, and that entire table is readable by anyone who sends a plain, unauthenticated request.

Not a theoretical anyone. You can see it on any Bubble app from a terminal:

# lists the app's data types
curl -s https://APPNAME.bubbleapps.io/api/1.1/meta

# returns rows if the User type has no privacy rules
curl -s https://APPNAME.bubbleapps.io/api/1.1/obj/user

If the second request comes back with records, that data is public to the whole internet. No login, no token, no clever exploit. The app in the browser looks completely normal the entire time, which is exactly why this survives to production. Nothing in the editor turns red. The database is just quietly answering the door to whoever knocks.

This is the most common serious finding in Bubble apps, and it is the one the platform built its dashboard to catch. So why is it still worth a human?

Flagging a gap is not the same as closing it

The dashboard tells you a data type has no privacy rules. That is the easy half. The hard half is the rule itself, and a scanner cannot write it for you, because the correct rule depends on what your app is for.

Who is allowed to read a given row? The user who created it, and no one else? Any logged-in user, but only some fields? A team, defined by a link two data types away? These are questions about your product, not your code, and the answer is different for every table. Set the rule too tight and the app breaks in ways that are obvious. Set it too loose and you are back where you started, except now the dashboard is green and you have stopped looking. The second failure is worse than the first, because it comes with a false sense that the work is done.

There are three more places the dashboard's reassurance runs thin:

Its deeper checks are gated. The genuinely useful ones, database exposure, unprotected backend workflows, Swagger exposure, sit behind higher-priced plans. On a lower plan you get the headline, not the detail.

Hidden is not hidden. A field or element marked hidden in the editor is still sent to the browser in the underlying data response. It is hidden from the eye, not from anyone reading the network traffic. A tool that checks your rules does not always check what actually ships.

It cannot see your app from the outside. The dashboard reports on your configuration. It does not sit where an attacker sits and read your public endpoints back to you, which is the only view that tells you what is genuinely reachable rather than what should be.

Why I looked at building a tool for this, and didn't

The honest part. When I started looking at Bubble, my first instinct was to build a scanner, the same shape as the plugin I built for Framer. I stopped for two reasons, and both are worth knowing if you are weighing a tool against a person.

Bubble already owns this space. The Security Dashboard is theirs, it is free on paid plans, and they got there by acquiring the best independent tool that existed and folding it in. On top of that, at least one respected agency already gives away a free external scanner. The automated-scan job is done, three times over, and none of those tools can write your privacy rules for you.

Because that is the part software cannot do. Reading endpoints and flagging missing rules is mechanical, and the platform has it covered. Deciding the correct rule for each data type, and then verifying from the outside that the fix actually closed the hole without breaking the app, is judgement about your specific product. That is a person who has done it before, not a scan.

What a real Bubble audit finds

Put together, the findings that matter on a Bubble app look like this. Whole tables readable through the Data API because a privacy rule was never set. Fields marked sensitive or hidden that ship in the response regardless. Backend workflows configured to run without authentication, callable by anyone who finds the endpoint. API keys that ended up in client-side code where the browser, and everyone in it, can read them. Every one of these is invisible from inside a working app, and every one is findable from outside in an afternoon by someone who knows where to look.

That last clause cuts both ways. Findable by us, and findable by anyone else.

Check yours

Run Bubble's dashboard first. It is free and it is a real improvement, and for a lot of the exposure it is enough on its own. If it comes back with a list of missing privacy rules you are not sure how to close correctly, or you would rather know what your app actually exposes to the outside than what its settings say it should, that is the audit we do: we test your live app from where an attacker stands, tell you the right rule for each finding, and verify the fix held. You can request one here.