First of all thank you all for the great work developing this tool and providing community Q&A : I’ve been using WeWeb for only a month and I already feel at home
I have a question regarding the security issues related to the Supabase Auth plugin. Is it possible to limit access to the config of the Supabase Auth plugin only to certain members of my Weweb organization ?
Long story short I’d like to have two profiles :
Admin / Owner Profile : can change app users roles, can edit the Supabase Auth private key, can do pretty much anything with the auth plugin
Contributor Profile : typically designers, product builders, anyone who can edit my app (and this will eventually happen) but NOT access to list of users, or change user roles
Basically, for security and data privacy reasons I want my contributor profile to have as much access to data as their own personal account gets.
But if they can change their own user roles or any app user’s role using the Supabase Auth plugin config, they virtually get access to any sensitive part of my app and data.
Is it possible in any way ? (I’m the only org user right now so I don’t really now how much I can customize roles / access rights in a bigger org)
Thank you !
Nicolas
EDIT : I did not find it in the search at first, but this issue is related to this one : WeWeb Security Concerns
Right now, it’s not possible to restrict access to plugins to certain contributors in your WeWeb workspace unfortunately. All members of your workspace would be able to view the configuration of plugins, change the config of the Supabase Auth plugin, see the Private API key view users, and change their roles.
Adding different roles to a WeWeb project or workspace is on our roadmap but hasn’t been prioritized yet. Is it something you would need within a specific timeframe?
In the meantime, as a workaround for your use case, you could remove the Supabase Auth plugin and make an API call to a Supabase function instead to signup and login users. That way, people couldn’t see your list of users and change their roles in the WeWeb interface. Your admins would lose the benefit of the native integration, but you’d regain full control of what all contributors can or cannot see.
Thank you for your quick answer !
Sadly the supabase auth integration is one of the major arguments in favor of WeWeb in our technical stack
We wish to handle all security aspects with Row Level Security on the Supabase side, and having a secured knowledge of who’s making a call to our DB is the pillar to this.
To be honest we could live with the contributors to our site being able to edit roles (that would force us to create a superadmin role not editable through WeWeb supabase auth for critical stuff but that’s legit)
Yet the free access to the private key is not far from being an absolute no go for us
As I guess this would be a no go for most of the structures using WeWeb (at least those using supabase auth), would you consider just removing the feature to see the key ?
I don’t really see the point of making it accessible (concerned users will have their own admin account to connect to their supabase instance and find it again if needed). More than this, I feel like having no API at all being able to access this key in your DB would be a major diminution of possible security flaws !
Do you mean removing the toggle to see the private API key in plain text ? It was made possible to easily copy/paste the key from Supabase to Supabase Auth plugin and make you able to check they are the same.
I understand your concern, I think it’s doable and it would make sense. But be aware technical people could still access it even if we remove the toggle or the field itself, as the plugin settings are loaded in the editor so we can make admin API call to parse your database and display your available tables and columns in plugin actions or make your users manageable from the Users panel.
Thank you very much for taking the time to answer here and on the other post !
I still have a few questions and remarks for you
About removing the toggle : yes that would be great I understand that it won’t prevent a sophisticated (or at least tech-informed) attack, but it’s already a great thing to prevent a too easy access to our service_role key !
There is one point I’m not sure to get in your explanation : I get that the service_role key is used to both get / set users and roles, and also to get the information_schema for editor purposes (especially on CRUD actions, and it’s indeed very practical to use), but it’s only a parameter for the supabase auth plugin. What happens if I don’t use the auth plugin, only the basic one ? Will the tables and fields list just not be available in the editor ?
And finally I have one question that may be naive : why not do all admin Supabase API calls through a proxy on your server that would just add the service-role key to headers and do the request server side ? From what I understand this could serve both functional needs for the weweb editor and our worries about access to the service_role.
About removing the toggle : yes that would be great I understand that it won’t prevent a sophisticated (or at least tech-informed) attack, but it’s already a great thing to prevent a too easy access to our service_role key !
I agree, I will ask the product team and see if we can make the change
There is one point I’m not sure to get in your explanation : I get that the service_role key is used to both get / set users and roles, and also to get the information_schema for editor purposes (especially on CRUD actions, and it’s indeed very practical to use), but it’s only a parameter for the supabase auth plugin. What happens if I don’t use the auth plugin, only the basic one ? Will the tables and fields list just not be available in the editor ?
Oh you’re right, so it’s only required in our Auth plugin, it probably means we dont need it to retrieve the schema. So we can probably make it optional at the cost of losing access to users management feature in the editor.
And finally I have one question that may be naive : why not do all admin Supabase API calls through a proxy on your server that would just add the service-role key to headers and do the request server side ? From what I understand this could serve both functional needs for the weweb editor and our worries about access to the service_role.
It was the main solution I was exploring indeed. It’s already a pattern we are used to. For example we have a few microservice where their only purpose is to hide the API key and restrict his usage to the specific endpoint we defined around it (Airtable, Smartsuite,…) because such services api key was not made to be used from a front end. Maybe we should take a similar approach with the credential with use in the editor as we have now many users building with a whole team and sharing sensitive stuff with each others.
The issue is as we plan to allow people to build and publish custom plugins themselves in WeWeb, they will not be able to follow the same pattern (unless we provide a way to write custom server code but it’s not planned yet).
Anyways, we will try to figure out how to better manage credentials in the editor, thanks for your feedback!
I understand that it won’t prevent a sophisticated (or at least tech-informed) attack, but it’s already a great thing to prevent a too easy access to our service_role key !
Will the tables and fields list just not be available in the editor ?