The User should be protected by privacy rule so not found in searches…the Users Profile, since it is a marketplace there should be a data type for Profile or Store or whatever type of marketplace it is, that is publicly visible via a search.
It is a solid approach, and more developers should read more books on how to market effectively…every marketing book I’ve read (ok, I don’t read the books, I read the summaries) they all have that same sage advice, to provide value before you ask for value. More developers should also read up on body posture and signals. Recently I watched a really interesting video regarding the topic and it was mentioned when making sales, never use a question intonation (ie: rising intonation) when stating a price, always use a falling intonation.
I understand…but everything in Bubble comes back to the User data type, which is the most important data type to secure for most apps, and is likely the most difficult to restore properly and where most of the sensitive data should be stored…of course this is just generally speaking and maybe more true for my approach to building and database schema than it may be for other developers.
Well a User would have access to themselves, and could use a Promote admin workflow on themselves if it’s not protected with workflow conditions anyway. And then they can do it to everyone else once they’re an admin
Yes which is why your tip on putting conditions onto such workflows is valuable and helpful to make developers secure their apps more effectively.
BTW, a way to protect against this is with a database trigger change. Most apps will have a known number of Admins…so create a database trigger change.
When User role now is Admin and User role before is not Admin: Workflow action, do a search for Users whose role is Admin:count is greater than the known number of Admins…change user role to something other than Admin…
This will make it so that a bad actor who changes their role to Admin in the database will automatically have that role changed back to something else. You can also use actions to flag this user in some way as well.
This is a more general category of things you could scan for called “accepting client side parameters.”
RE: the discussion about protecting the role. You could also not include any workflows that change the role to an admin. So for example, say you have a role option set that has Free, Paid, and Admin. Your backend logic would, depending on “stuff,” change it to Paid, without relying on any user-provided parameters. You have no workflow actions that ever change the role to Admin, you only change it manually in the database. This is also theoretically secure.
see your pages as hackers do by forcing all elements to be visible
see what actions attackers might exploit in your app
detect and understand page redirects
This is still experimental so do send through reports for any bugs you encounter! We had to rollback the enhanced page redirect analysis that takes this into account a couple of days ago, but relaunched it with this update, so we’d encourage you to re-run page redirect analysis.
By popular demand, the data explorer now shows the total number of results (count) found for each data type, so you can see at a glance if the numbers seem reasonable to you:
I finally had a chance to try NQU Secure today. Very impressive service! The audit results are quick, clear, comprehensive, and actionable. Thanks a lot, @georgecollier, for this valuable contribution to the community. I hope the various issue flags I submitted serve as a small reciprocal contribution that helps you further improve the automated analysis and feedback.
Thank you, much appreciated! Based on these, I have further refined the API Call analysis. You can re-run the audit and see if that has any improvement for you.
I’ll touch upon one of your flags here as it’ll be relevant to others too. In summary, you correctly pointed out that we mark server-side redirects as a pass, but do say in the further information section that this is obfuscation rather than security which contradicts the Pass rating.
There’s a couple of reasons I decided to make this a pass:
if every issue is flagged as a vulnerability, people give up and don’t actually fix any of them
if SSRs are flagged as issues, then it’s impossible for that page redirect checkpoint to ever be a pass for a restricted page
the server-side redirect issue is already on Bubble’s radar. There’s steps they’re taking to improve this, along with general app security/defaults, which is great.
In the future, I may attach a ‘sensitivity’ or ‘risk’ value to each issue. That takes into account not how serious it is, but how exploitable it is. For example, open Data API endpoints are very risky as they’re trivial to find. Missing workflow conditions, for example, are less risky as they’re harder to find.
That’ll allow users to filter and decide what level of bulletproof they want their app to be. Of course, I hope everyone will make it as secure as possible, but failing that, I will do whatever I can to make it worth their time to fix at least some issues.
What’s the point of the visibility scanner? Isn’t this effectively the same as making every group visible? “Just assume everything is visible” should be good enough.
It should be, but seeing is believing, and in well built apps with plenty of reuseable elements, it’s not always straightforward to identify what you have put on a page,
In the same way, ‘assume privacy rules are the only thing you protect your data’ is correct - it doesn’t mean people know what data is public and believe that it is public.
But privacy rules aren’t all or nothing like page visibility. I guess reusables could be a fair point but really if you internalize “all of it is public” then that page seems pointless.
Are you planning on releasing a toggle for LLM-enabled features?
I’m very excited to announce that NQU Secure now includes an analytics suite - free for every Bubble app!
No cookies, no limits.
In my experience running an agency, I’ve seen countless apps operating without basic analytics, making it impossible to understand user behaviour and improve the product effectively. Without proper tracking, you’re essentially flying blind - unable to measure growth, identify bottlenecks, or make data-driven decisions.
Our new analytics suite solves these challenges with:
real-time user activity review
user journey exploration, linked to their Bubble account
privacy first design, with all analytics are stored on our EU-based servers with zero cookies required
This is of course a foundation for future features including workload monitoring, error tracking, and advanced log capabilities.
The analytics dashboard is designed to be simple, intuitive and actionable. It’s not designed to replace a powerhouse tool, because those are a pain to use. It’s designed to give you the key information you need to know who’s using your apps, when, and how.
