Hi all,
we all know that public rules makes data public… ok, but how?
From the console browser?
If so, what I have to type to be double check if I have set correctly my privacy rules?
Also field names are visible, or only the values?
I did not found these answers myself.
Thank you!!
Wrong. No rules makes data public.
Rathed, private rules make data private upon criteria.
mmm ok but I mean, if I flag “email” field on the User table in “Everyone else (default permissions)” I’m actually able to Do a Search for in a workflow checking if that email exist even without being a logged in user.
So my question is for security purpose, who else is able to see these emails?
By checking the box for the email field in the “Everyone else (default permissions)” you are making it so anyone can see that User’s email
The point of privacy rules are to uncheck that box if you don’t want anyone to get users’ email addresses
And the expression at the top should be something like Current user is logged in if you only want logged in users to see other people’s email addresses
Some other expressions are This User is Current User if you only want someone to see their own email address and no one else
I’m with you, I got all of these points.
My guess is… who is “anyone” and how can access these emails?
I mean, there might be needed an attack to Bubble.io to discover this data, or those are simply available browsing my app and making some sort of query from the browser console?
I am not sure if someone could make a database search manually via their browser, fairly certain they can’t.
But the privacy rules are a safeguard to ensure users don’t see anyone else’s sensitive data.
So if you keep that email checkbox unchecked for “anyone”, when you have a repeating group on your page searching for Users, the privacy rule will prevent the email from also being downloaded to the user’s browser (which they would then be able to poke around in their dev console and find it)
however, if you are a user not logged in and you click on a button that triggers a workflow searching in the user table for a specific email, you are able to do it if the email field is open to everyone.
So I’m worried about the ability of an unauthenticated user to retrieve all the emails, I’m just trying to figure this out.
Yes so put a condition on the workflow to only run if a user is logged in, and uncheck that box for anyone to see emails
eheh is not so simple, I use a double login method due to the purpose of my app, so I need to search for existing users email before making the second authentication in my app. That’s why. I was also exploring the way of making this query in a backed workflow and passing the arguments back to the frontend with the return API action, but this require to make the API public, so I guess that the risk is practically identical.
The best way to achieve this I guess is to encrypt all the data and query for the encrypted data.
Need to do some test about this.
I often wonder this myself. My guess has always been that it requires a browser side search where someone’s been able to reverse engineer Bubble’s encryption (if that’s what it’s called) to be able to send any properly formatted search requests.
I think I once read that @wesleywsls or @vnihoul77 figured out how to do this. Within the browser’s developer tools, if you switch to the network tab and inspect the call named mget (which appears whenever you run some search), you’ll see that the body parameters for that request are always x, y and z. But values for those parameters aren’t human readable. So search parameters are somehow encoded into one or all three of those parameters with a salting / hashing mechanism that (for the most part) only Bubble can decode. If team Flusk actually did reverse engineer how to inject search requests in browser, then I believe that was their entry point. And if they could do it, then certainly any motivated hacker could as well.
great useful findings! Thanks!
This is reassuring me a bit, still, I’ll check to encrypt data before exposing them. I already use an AES plugin to do stuff like this, but the login sequence require some more deep testing.
If we’re talking about data, there is a lot of different ways to publicly access your database. So you could add as many security layers as you want, the key point is really to build strong privacy rules.
Once you’ve done that, try them carefully and regularly (i.e after each push) using a tool (like ours) or by designing a privacy rules check page.
This sounds like a good idea, but don’t forget that encryption methods performed in the front end would be public and therefore might be the key to decrypting your data while keeping a false feeling of security up.
Again I’d recommend exclusively focusing on the privacy rules for the Bubble database-related data and if you’re really concerned about security, hire someone for a pentest once your app is built!
Cheers! 
