WeWeb & Supabase - Security Concerns

Ask us anything
1

Hi everyone and the WeWeb team!

I am writing because both we and our customers have security concerns regarding the WeWeb platform. First, we absolutely love WeWeb and enjoy building apps with it a great deal!

However, one major concern we have is that WeWeb does not provide specific details on how our API tokens are stored and secured within their infrastructure. We use Supabase, and to utilize the Supabase Auth Plugin, we need to store the service_role key in WeWeb. This key grants access to all data stored in the specific Supabase project. WeWeb’s Data Processing Agreement for Supabase states, “WeWeb does not store any data passing through this plugin except when using the cached mode. Plugin setup and API tokens are stored on AWS.” This means they store the service_role key in an AWS cluster in the US, but there is no information on how it is protected.

  • Is it encrypted end to end?
  • Can the WeWeb team view my key in plaintext? If so, how do you ensure that we are not exposed to the threat of disgruntled employees, social engineering, simple mistakes, etc.?
  • How do you protect our data from potential leaks on your end?

Perhaps someone from the team could provide some insights?

Thank you very much,

Max

4 Likes
2

Anyone from the WeWeb team? I think this is a very important topic. Security should always be our first concern when we build web apps.

3 Likes
3

So, I checked the logs, and the service_role key is indeed not encrypted on my end. I’m guessing that WeWeb uses the key to check the user’s role on page changes. That means it is probably not encrypted on the server either.

Judging by the fact that I can see the service_role key in my Editor in plaintext anytime, I believe that WeWeb team members can also see it when they open my project. I never know when a WeWeb employee opens my project, which means I’ve essentially opened up my key to anyone on the WeWeb team. Consequently, everyone from the WeWeb team can access all my data on Supabase. This poses a huge security risk and practically invalidates Supabase’s SOC2 certification.

What concerns me even more is that no one from the team has responded to the thread. To me, this indicates that they are either not aware of this issue, which is bad, or they know and are not informing us about it, which is equally concerning.

I think one quick fix would be to make the input of the service_role key optional in the Auth Plugin and disable the user roles for the particular project.

I’m sorry to tag you directly, @Joyce, but can you please shed some light on this?

4

No worries, @Max. Let me ask the tech team and get back to you on this one.

2 Likes
5

Hello Max, following up on your message here.

  1. The keys are crypted on our DB

  2. Only WeWeb team members with an admin role can access your projects - this is to provide better and faster support when needed.

Those of our clients sensible to this issue usually self-host and only use the keys to a sandbox DB or their staging DB in WeWeb’s editor. Once ready, they get the code and update it so it points to their production env.

Alternatively, we can sign a legally binding agreement to protect your firm against misconduct from our employees.

Hope this helps!

6

Hi Raphael,

Thank you for your response; I really appreciate it!

Unfortunately, this is not good news. This means that if I want to create a secure web app with WeWeb, I need to:

  • Be on an annual subscription
  • Build the backend twice
  • Self-host the application
  • Change the exported code manually or via automation every time I publish changes

This complicates building apps with WeWeb tremendously and kind of defeats the purpose of a NoCode platform if I have to do all these manual steps where technical skills are required. We are coders, so we can manage this. However, this ultimately means that non-technical people cannot build secure apps with WeWeb and Supabase using the Supabase Auth plugin.

Also, we cannot invite freelancers to our projects because they will get access to all Supabase keys of all projects in the workspace we invited them to. Even within our team, we cannot manage roles. All our employees will be admins for all projects in our workspace. That makes it hard to build professional apps that care about security.

As of now, we cannot use the Supabase plugin for professional projects.

Maybe a “quick fix” would be to make the service_role key optional in the Supabase Auth config. Sure, we would lose some functionality but gain a lot of security.

What do you think?

7

Hi @Max

It’s not a WeWeb thing, it’s a Supabase thing. The correct solution is for supabase to allow managing settings on the generated key to restrict what you can do with it. It’s a really common pattern. For example when you create a private key on Airtable (or Xano) you can select exactly which access you grant to the key, per workspace, per project, per operation.

We will explore if there is a way to make the service role optional while retaining the core features.

Without admin access we may not be able to parse your database and provide you the list of tables and columns anymore for example, it would probably defeat the purpose of having a plugin for many people. It would also require you to be connected as a user first to edit your project and RLS will impact your experience while editing. So for your collaborators to be able to work with your project you will need to give them admin access through RLS and so it will defeat the purpose to make the service role token optional in a way.

Still, I 100% understand your concern, nocode platforms have to step up their game and move away from the pattern of giving full access to each other to communicate, by offering a way to manage the connection between them with more granularity.

On our side the only thing we can do is to require only the minimum amount of access we need, but it depends very much on the external service we’re connecting to.

Note =>

I’m guessing that WeWeb uses the key to check the user’s role on page changes. That means it is probably not encrypted on the server either.

No. The service role key is only used in the editor, not in production, not even server side. The service role key is used to generate a front end sdk admin client with admin privilege, so you can manage your users from the Editor (Auth plugin) and we can display the table and columns on the CRUD actions.

8

Hi @Alexis,

Thank you for the information!

I agree, Supabase’s access control with just one key that can do everything is a problem. I understand that you have to find a way to deal with that on your side.

We would definitely invest the effort in our projects and create auth users with adjusted RLS just for the WeWeb editor. The way it works now, we cannot use the Supabase plugin at all.

9

I mean, I gotta give this one to @Slavo, as he was sort of right when we spoke about this and I was sort of wrong. Supabase is ideally used with a Backend, such as Fastgen / Edge functions for example. There you handle all your secrets, and you usually just hit the api to get the Supabase data from the API, this way you don’t need to even touch Supabase in WeWeb, if not for the calls. But yeah, that defies the purpose of the Supabase plugin entirely, but in many cases, would be a better approach.

In an ideal developer world, you wouldn’t even touch Supabase on the front-end. The fact that there is a plugin for WeWeb to access Supabase directly is not really the intended usage I think - in regular development.

10

I don’t think it is a good idea to include Fastgen in the mix. Doing so will lead to the same issues: granting access to your database to an additional company. Fastgen lacks security certifications, and as far as I understand, they host their services in the US. This compromises Supabase’s SOC2 certification and does not comply with the EU’s data privacy regulations (GDPR).

Supabase is designed for frontend use. However, the issue is that WeWeb requires the service_role key for Auth plugin configuration. But as @Alexis mentions here, I believe this requirement can be made optional:

11

The more I work with Supabase, the more I’m building with it as an API - delegating to functions etc. especially for complex operations. Doing all the stuff on the front-end becomes unsustainable in the long run, and if you have many tables, the time you spend on setting up RLS, could be spent by building a proper API. Also, when you’re using Supabase client-side, you’re opening yourself to a huge amount of vectors where people can intrude, as you basically open your whole DB via their PostgREST to the public. That’s why I’m thinking more and more about switching to the backend approach. But yeah, if you have good RLS, should be fine.

When you do things on the front-end, it’s also very unsustainable in case of changes, e.g schema - table name, new function gets introduced that replaces the old one. When you do this on the backend, the transition is more smooth, as you just modify the end-point to fit the old data structure, with the new data. This way you only need to make the change on the BE and not also on the FE most of the time.

Overall, the BE vs FE in Supabase, is about patterns that imo save time, and I like saving time :slight_smile: And yeah, if you wanted, you could even do this with REST entirely, by just sending the Authorization as a parameter, thus resulting in not even having Supabase plugin etc. But this would be a little extreme imo.

Edit: I had a few apps actually built directly on Supabase via using the WeWeb plugin, or by connecting via flutterflow directly, and I can tell you, once the project gets bigger, you begin to pay the cost of taking this shortcut. I saw whole apps needing re-doing just because they needed more complex logic, that you can’t handle on the front end, and also because it is unsustainable once you have 20-30+ tables. Usually, I just use Supabase hybridly - directly to access simple tables/views and to make operations that take a maximum of 2 operations, e.g. crud / update. The rest gets delegated to the Postgres / Edge Functions. Doing everything with the front-end plugin just asks for additional costs to port it to an API later.

Supabase is a great helper, but a terrible boss. Once you get too addicted to it, you get stuck and limited by not having your own backend. But yeah, that’s for huge apps, for MVPs you don’t even think about this.

12

+1 on not directly using Supabase.

We have a client who insisted on doing it this way. Initially, I didn’t understand the appeal of adding another layer, but I later realised the drawbacks.

1 Like
13

In an ideal developer world, you wouldn’t even touch Supabase on the front-end. The fact that there is a plugin for WeWeb to access Supabase directly is not really the intended usage I think - in regular development.

I strongly disagree. Supabase is providing client SDK for many platform, including browser, because it’s the expected usage. Its a database + an opinionated API packaged together, including Aut, RLS system and Realtime.

If the API doesn’t fit your needs it doesn’t mean you should use supabase on the backend, it means you probably need another tool, like Xano.

Adding another API on top of supabase will only increase the latency and doesn’t make any sense to me as you will lose many of the benefit supabase bring to you as you will have to develop your own auth system, your own business logic rules to replace RLS, your own websocket system for realtime. So, if you need a database behind another API layer like fastgen, pick a database tool and host it side by side with the API, don’t pick supabase.

Supabase is obviously not good for every usecase, it’s why there is so many alternative with different tradeoff and patterns, building an API layer on top of supabase sounds like a terrible idea to me, except if you’re in a process of moving away from supabase.

Maybe I’m wrong but I wanted to share my opinion about this :thinking:

2 Likes
14

That’s why I mentioned the hybrid usecase, obviously you wouldn’t build an api on top of the SDk, but connect directly. Doing at least the functions on the backend and hitting them via postgrest is the idea, but doing complex operations like chaining crud on the front-end is just a straightforward bad idea also for latency, as you mentioned.

Btw. Their edge functions use their sdk so it’s not entirely a bad idea.

1 Like
15

I totally agree, Alexis. I don’t see why you should build an API layer on top of Supabase. For complex scenarios, we use Edge Functions. For standard database access, we use the auto-generated API by Supabase. Adding a tool on top of that only increases complexity and decreases security.

A hybrid scenario makes no sense to me.

16

Just to make this clear. By hybrid scenario I mean delegating to Pgsql functions and doing simple operation in weweb workflows.

17

That we can agree on :wink:

18

Capture d’écran 2024-02-28 à 17.42.50
Capture d’écran 2024-02-28 à 17.42.50946×746 36.8 KB

Will be released ASAP.

  1. Make the service role optional
  2. Not possible to see and copy/paste the key

What you lose when not provided:

Required if you want to manage your users and roles from the Editor or restrict access to a page for a specific role.

It’s a first step to improve security around credentials with our supabase integration. Let me know if you have any feedback.

5 Likes
19

That’s great to hear, thank you!

20

That’s excellent news indeed

Thanks a lot for your very quick action on this !
I can’t wait to carry on exploring weWeb and going further with our apps :slight_smile:

Thanks again,

Nicolas