Oh yes exactly, but what I mean is as long as “Thing X” are searchable, then it’s like all “Y” are exposed as well.
One just has to querry all X to find all Y. (lets say all Y are associated with some X)
Exactly, if Thing X cannot be found in searches, but Thing Y stores X on a field and the user can search for Y, then they can do a search for Y to find the IDs of X.
If “page” is just a number, then it’s not secure as the frontend can send whatever number it wants.
It would be secure if “page” is written in the DB and you reference that DB value in the condition. But if I understand your usecase, if page is just a number probably coming from a reusable element or a table etc.., then it’s not “secure”
Yes I’m well aware of that. But I’m talking about the check. So say you send the number 5,000 even though you should only be able to send 1-10. A server-side check will still see that the value is wrong. Basically, is there any difference between a parameter in a backend workflow and a custom event return value in terms of being checked?
Thank you George.
I understand how it works now, but I can’t say I understand why would Bubble allow to edit something you don’t have rights to see 
EDIT: especially when the datastructure of all bubble apps is by design exposed
The other thing is that you can search over fields you don’t have rights to see.
Suppose an Employees table I can access but I can’t see the salary field.
I can still ask yes/no questions about the salary field by doing something like Find me all employees where salary > $100,000. Even though none of the returned results will have the salary field visible, I know it’s greater than $100,000 because it matches the constraint. It allows you to work out a value by inference. That can be pretty dangerous in some people’s implementations (e.g when storing a user API key on an object directly rather than in its own data type)
You see, that’s why I want to understand and I don’t like just accepting the usual “privacy rule make things secure” we get served.
Also, VIEWing is not the only concern here. Let’s say one of the employee goes crazy, he IS able to EDIT all it’s coworkers salary and “Make change to a list of things… “ Salary = 1 million $
All that means that a data is truly secured only if the sensitive data is stored in a different DB datatype AND it is accessed through backend workflow AND that private object is removed every single right through privacy rules.
My understanding of the only solution for real security : Given your “Employee” example. The salary should be stored in a different datatype objects, lets call that “Salary” which is type number.
”Employee” should NOT hold any reference to “Salary”.
”Salary” should hold a reference to “Employee”.
And if you want to search for Employees with Salary > 100000, you need to query a backendWF that will bypass privacy rules, search for Salaries objects, fetch all “Employee”, and return a [table of Employee’s IDs]
Wait a minute. I am certainly overthinking this after a long week on a friday afternoon 
but …
If privacy rules do not prevent someone to edit data it cannot see. What prevents someone to edit it’s own customer’s “role” user attribute? (90% of apps probably have User field “role” which is in fact a type Option set)
Because if autobinding isn’t enabled, a field can only be edited through a workflow, and you can (and should) secure the workflow that updates the user’s role with an appropriate condition.
Whilst a user can run any search, they can’t run any action. They can only run what you’ve configured, and the only thing they can manipulate are the client side values your workflow references.
So, I can’t just go to my user profile page where you’ve set up a Make changes to thing that updates my first/last name and ‘add’ a new field that sets the role to admin. Because that’s not what your workflow defines.
1 Like
Ok, so my wish list is fine in term of a crazy dude who would want to ruin everybody’s wishes.
And, I hope that’s my last brain bug and question: if a frontend user is genius enough to make changes to frontend data, alter request querries etc… won’t he be able to make up a workflow from scratch without any security ?
No, not at all.
Workflows can only be executed based on your app’s logic. You’re confusing data reads, which are managed by privacy rules, with writes, which are managed by workflows. Reads can be done arbitrarily, workflows can only happen through your app logic.
1 Like
To be clear, things can only be created/updated/deleted through a workflow, UNLESS auto binding grants the user permission to modify the Thing arbitrarily.
1 Like
Do we need “constraint” rules? Or at the very least a checkbox like we have for “find this in searches” / “autobind” etc.
Probably will never happen knowing Bubble.
I know I want a new version release that treats any search constraint on a field the user’s privacy rules don’t permit them to access as an empty search with the same behaviour as ‘ignore empty constraints’
1 Like
Let’s hope ̶B̶u̶b̶b̶l̶e̶ we are protected from fast queries so one can’t really does that “guessing salaries” game at a large scale.
Thanks @georgecollier for all your help in this thread
Hello again, it has been said that a condition implying a database object on a frontend workflow would trigger a check on the server side, and furthermore it was said that the condition does not require its elements to be visible from the frontend.
I have done that in the example below. However, the condition fails and the WF does not run.
That first “Do a search for” returns an object with a blank “password”. Because the condition is indeed evaluated on the frontend and requires the password to be visible. Which is not what has been said in this thread.
This is from within a RE with 2 parameters :
- “list” : which is an object of type list
- “list_password” : which is a text
I tried several writing variants, this leads to the same result :
The inspector shows that the frontend WF condition fails, because the password is empty.
What am I doing wrong?
You cannot see the password. This is the expected behaviour.
However, you can still search on it.
So, if Do a search for Lists where password = create_wish’s list_password first item is not empty then you know there was a match, even though you can’t see the password.
You don’t need to take ;first item’s password and compare it to the wishlist password, because you’ve already done that in the search constraint.
1 Like
Thanks, that make sense, I should have read better the previous posts.
Interestingly though, filtering my search on unique_id does not return any result for some reason.
Filtering on something else like slug, does return stuff.
I don’t know why. And I 200% did expected learning so much from a weekend project 
