Is it save to use the conditional rendering function if a user with a “lower” Role isn’t allowed to see an element? Or is it possible for the user to manipulate the code so that he can see the element? (Like it’s possible with the “CSS Display” setting)
1 Like
Hi @tillyboard 
No, it isn’t safe. When it comes to security, you should always protect the backend and never trust the frontend.
Here’s a live stream we did on the topic.
2 Likes
Hi Joyce.
Wanted to followup on this, as its still a little fuzzy after watching the videos and reading the docs.
Most of the security examples there are focused on changing data in the back end, so recommend using RLS (Supabase) or endpoint access control (Xano) to mitigate.
But it is not clear to me how to handle ‘in-app’ or ‘frontend’ concerns. Two common use cases specifically come to mind.
- Conditional rendering based on user role
Ex: Page showing all authenticated (logged-in) users who is attending a specific meeting. On this page, if the user viewing the page is the meeting creator (or is “admin” role, as another example case), render a “remove” button that triggers a workflow to remove any of the other users from the meeting.
I understand the actual database change (delete) would need protecting (via RLS or the endpoint mentioned above), but are you suggesting there is some other/better/more secure way of hiding this “remove” button in the front end than conditional rendering based on the user role or whether their user ID matches that of the meeting creator? In such an example it is not practical to have an entirely different ‘admin’ page for this simple action.
- Workflows
Is it possible to hide/secure an actual workflow itself? If we need to process something in the workflow that we do not want the user to be able to see, is that possible?
Ex: We want to allow users to ‘sign up’ for our app, but only if they have a signup/invite code (which we’ve stored in our database). So we need to run a workflow when they submit the signup form that compares the code they provided with the ‘real’ code in the database.
Or perhaps we simply don’t want users to know exactly what we are doing in a workflow.
Ex: If we have an e-commerce system and when a user places an order we need to add some private fields to the order. Maybe we charge a commission on each order and that value varies by user. Eventually, when stored in the database, this value could be protected by RLS, but what about as it is being retrieved, used, and passed along in the workflow?
Sorry if some of these concepts are basic, just trying to find exactly where the lines are in WeWeb so we can spend time building the ‘right’ way up front. I know many security concerns can probably be addressed using Supabase edge functions, but it would be great if you could help define when we should be looking outside WeWeb verse when we can use tools in WeWeb. This is especially important since some plugins (such as the Stripe plugin) are in a middle ground and provide an exception to the general rules.
Thanks!
1 Like
I think at 27:00 when a similar question is asked he’s more or less answering it. He’s saying 2 layers of protection, the first is for ‘non malicious’ users by hiding the button on the frontend (so conditional rendering) and the second is the endpoint/satabase auth protection in case a hacker ‘finds’ the button in the code and tries to run the code or reach the api