Hi,
When managing user roles, a common practice is to have roles defined as an option set and a field on each user profile which is the user role.
The role needs to be readable by the front end for obvious reasons of hiding/showing stuff depending on the user role.
How is this secured? How to prevent the user to change its own role if he figures out how the app works through the console.
Thank you for your time
Interesting question, because as far as I know Option Sets are always downloaded by the frontend and are accesible by an attacker. One would think that it wonât be difficult to change the role from console and access hidden parts of the app.
However, I think that, if applied in a When page is load workflow, a rol-based conditional prevents the user from accessing certain pages completely. He will get a 301 redirect and wonât be able to load the page.
Also, I also think that Privacy Rules protect sensible data to be retrieved from DB, based on server-side checks, so even if you change the value in the frontend, you wonât be able to access data properly protected by Privacy Rules.
Though, I believe frontend elements (not the data retrieved by them), hidden based on client-side role checks, can be exposed.
Indeed, everything hidden on the front end can be seen. Any real sensitive stuff should be hidden on the server side and never under no circumstance reach the front end.
Security should always be set at the server level with backend workflow.
Lets take as an example, the user signup. It seems to me that this is not secure as the user could from its frontend modify the querry and get attributed a different role than expected, for example âadminâ.
How to prevent that? Are really every frontend action unsecure or is there something else running under the hood that is not well advertised and that guarantee security?
I once had a similar question, the answer is no it cant, my question was during signup can an attacker change the custom states thus workflow triggers to have another role or signup flow. The answer is no
Thanks for the feedback, do you know how this is ensured?
Iâm curious about this assertion. As far as I know, custom states can be changed at will by an attacker.
Therefore, if the Sign a user up action is setting a Userâs role field based on a value stored in a custom state, it could perform the attack. Could you shed more light on this?
Force server-side evaluation of workflow conditionals that check userâs role. See discussion in:
Option Sets are but thatâs not the same thing as the specific option set value in a specific field attached to a Thing
use Current User is Logged in & Current User is [Role]
If auto binding is enabled for that field by privacy rules, assume users can modify it unrestricted if they meet that privacy ruleâs condition.
Else, it can only be modified by workflows. Ensure that you have a condition on the role modification workflow to stop anyone running it e.g Current Userâs Role is Admin, to only allow admins to update other users roles.
Be particularly careful with signup flows. If your signup flow signs a user up with the role determined from a client side state or variable e.g var - user role, then that could be manipulated to specify any user role, as it is a client side input.
If you have front-end workflows that verify a userâs permissions, e.g Current Userâs Role is Admin, that cannot be manipulated by a user. The condition is evaluated server side, meaning Bubble checks the database for the userâs role, and is not vulnerable to manipulation.
