2024-09-18 - it’s quite stable now
2023-11-08: I *think* I got it back up now.
2023-10-31: fix for API
2023-10-27: demo is back up.
2023-10-19: demo is down – I ran out of cloud credits. I’ll try to put it back up this weekend
2023-10-18: added demo and link*
They need to allow us to hide /meta just like we can hide swagger.
However I’m still not sold on the fact you can access all fields regardless of privacy. Going to dig into it tonight to see what all I can expose about an app through various methods.
My completely baseless theory is its like the file upload endpoint, some essential Bubble functionality needs it (like the editor or something) and it wasn’t secured from the very beginning…
Try console.log(app) in dev tools. It shows all of the app information, including app ID, data types, option sets, API calls etc.
Also, hiding meta would just be obfuscation rather than security, but obviously obfuscation is infinitely better than no obfuscation all else being equal.
forgot about that. this seems like a major issue or am I missing something? I know it started under a showcase post but prob should be converted to a bug or…
I mean, if just knowing the DB structure allows someone to hack an app then something else has gone wrong in the app’s development, but generally yes, not publicising the DB structure would make it more difficult to find exploits.
I think it’s a bigger issue that endpoints are exposed in meta, and it even tells you which don’t require authentication. Just search for “auth_unecessary”: true and all of those endpoints are fair game for a hacker to have a go with!
I don’t think its a major issue because the app can be hacked but the DB architecture of a complex app is often proprietary and shouldn’t be publicly visible.
Although this can help me build my MVP intake by grabbing DB structures of apps with similar functions (kidding obviously).
Yes, I agree that this is not great. In the meantime, get your own here: rico.wtf. It’s super unstable, you might need a couple of mashes on that button.
Did anyone else know that all your DB are publicly accessible???
I knew my DB was exposed to the public
I didn’t know my DB was public but don’t really care
I didn’t know my DB was public & am greatly concerned about that.
0voters
P.S. I’m so glad I’ve never agreed to showcase any bubble apps → that’s basically an invitation to for everyone to examine my DBs
P.P.S.The zerocode DB map plugin, needed tables to be made available via data API for it to work, which at the time implied to me that the DB architecture is not publicly accessible
Yes - unfortunately your database structure is just the beginning. Bubble exposes A LOT in the JSON file like most Javascripts sites do, but bubble could do a better job to beautify them like others do.
In addition to your DB, you can also find your APIs, your API keys (if public) your password limit, your client side workflows, and a lot more.
I recently put together a security course that goes deep into this, and how to prevent other venerabilities in your app.
For the most part, the public data that is exposed, won’t hurt your app. But it’s unsettling, that’s for sure.
I’m not concerned about my apps being vulnerable; however, the DB structure in many of my apps is proprietary and NOT something I want to share publicly.
In fact, for an app I’m working on as we speak, I just pulled the DB of 4 similar apps (@rico.trevisan many thanks for a really awesome tool! ) and that helped me save a lot of time and trial and error for what I’m working on
In the JSON, each table is labeled as public.[table name], do they have to be public? Does bubble’s functioning require the DB architecture to be visible, OR is bubble taking shortcuts in not hiding such information?