If I use the REST API plugin in Weweb, are the API keys secured?
If not, what’s the best alternative?
1 Like
From what I understand, as long as the key is passed as a header inside the plugin editor, it’s secure. But if you’re storing the API key as a variable (which is exposed upon page load) or the API key is in the API URL you are calling (such as a parameter), then it would be exposed.
Here is a great Security 101 video that WeWeb published just a couple weeks ago that has more on this: Build secure web-apps with no-code tools - YouTube
No. You need to keep sensitive keys in and make the calls calls from your backend.
It would be great if there was a place to store the API keys securely inside WeWeb and request it like a variable.
It looks like I’m going to have to build (aka faff for many hours) a backend api proxy to handle the API request as there isn’t a secure way in WeWeb. As a nocode builder, this is quite a bit of code for me.
All I’d like to do is integrate OneSignal and have a email sign up form. Not so simple it seems.
I would not recommend using weweb to solve backend problems. That’s more akin to using Bubble. There are many standalone nocode API backends (e.g. Xano, Supabase, Fastgen Buildship, Comnoco, Pipedream to name a few) to solve this problem simply and in a world-class way.
1 Like
WeWeb is a front end builder, what you build will be executed in the browser and so everything end up exposed publicly.
What do you need to secure behind your proxy ? Which API calls exactly with which api keys ?
I’m geniunly interested because I already through about how to provide such capabilities in WeWeb, there is many way like improving the REST API plugin to allow defining secure variables inside and define a syntax to inject it inside your request when you toggle the “proxy request” feature.
But I think it’s not a good pattern. In most of the case, hiding an API key is not enough and could provide a false sense of security. If all you do is proxying a request you’re still allowing anyone to use your API Key with the endpoint url and payload you want, so I would need to make the request url static to avoid someone replacing it with his own endpoint url to steal my api key. But again, even if the API key usage get restricted to the predefined static url, someone could abuse it.
Exemple => If you decide to use such a feature to send api request to OpenAI, and protect the api key by proxying the request, someone could just ping and abuse this proxy endpoint and empty your credits. So we will need to develop a way to address this like adding a configurable rate limit but then you will want to make it depend of the connected user and it will become even more complex. In reality once we open the door, what people will ask us is to provide a backend.
But what I think is there is already many backend players and we should stay focus on building the best front end builder to connect with them.
But if there is usecases where a simple proxy, only to hide an api key, is enough and where there is no risk associated with the fact the proxy endpoint will be public and can be abused, I think we could develop something. I’m just not sure encouraging such a pattern is good, many people could be tempted to see it as a shortcut instead of developing their application in a secure and robust way.
1 Like
Hi Alexis,
Thanks for your thoughts and it’s insightful to hear the dilema in making such a decision. As, like you say, should you keep focused on developing what is already a great front end builder.
I can’t help with the technical side unfortunately and can only offer my perspective.
I know it is, and you refer to it as a “front end” builder, but I guess I see it more generally as a great website builder… to bring ideas to life. I’m not a developer by nature, more of a designer and marketeer with a lot of experience in ecommerce. That said, I have enough knowledge to know what makes WeWeb the best choice (using VueJS for one) vs the competition and it fits perfectly with my level of skill of using software. But I’m limited to working with nice GUI’s, not code editors.
The Supabase and other plugins are ideal to bring in that extra depth, the “backend” (or in my brain, it’s the database). Having the full Supabase integration has made it a lovely seamless experience that I understand and can work with. I just use the UI here and it’s got me almost to launch without ever opening up a code editor.
So the need I mention above is to have email newsletter sign up form on the website. Email addresses are then stored as users on one of the many platforms for email/sms/push notifications, etc used for marketing. I need full control over flows and sending this content out. In our case, OneSignal is chosen (because it’s integrated with FlutterFlow).
What I thought would be trivial, given how easy it is to work with something more complex like Supabase, turns out to be a deep hole of internet security! I totally understand you can’t integrate all the SDK’s out there, so I’m content with the need to work with Rest API’s where needed and the power that offers. It’s just that, I very nearly put the private API key into the header in WeWeb not really knowing of the dangers that exposes. Maybe it sounds obvious to many, but it’s just that extra bit of website coding knowledge that sits on the other side of the fence in my ability. You know, I see Supabase plugin is setup with keys, so why wouldn’t this work! Dumb I know.
Only now I know that plugins are built differently to the rest of the code and how it’s packaged and exposed, but I just honestly didn’t know this is how it all truly works. I’m too busy fussing over rounded corners and sliding animations.
So I did get the backend api proxy working as a edge function on Supabase… but with endless hurdles and only thanks to chatGpt, lot of research and videos. There’s always endless screaming errors when I go into the coding part, which is why WebWeb works so well for me. I get nervous opening the terminal, I then have to CLI into Supabase to create a new function, etc. Then more errors to wrap my head around, as I didn’t have docker installed, etc. It’s a frustrating experience as I’m simply out of my comfort zone.
Sorry if this is boring info, but I thought worth mentioning simply because if you’re not a developer, then perhaps the perspective is different. The great value of using WeWeb is its way of extrapalating out that layer of complexity and understanding so it just works - error free.
My experience with WeWeb has been really positive, actually enjoyable, addictive even and has been living up to the 10x mantra of building a website faster. But this API key situation is slow and worriesome. I’m not confident in what I’ve done and if it’s right. I don’t know if it’s even solvable, because as you say, it’s open to abuse in more ways than I know of.
Maybe there’s a solution out there to solve this. Maybe not. Thanks for considering this either way.
1 Like
Thank you for the analysis @Alexis !
From what you wrote the conclusion is that from nowhere in weweb are we able to make a 100% protected backend communication?
Not from the supabase plugin
Not from the OpenAi plugin
Not from the REST API plugin
So even if we use Buildship for example, the proxy you mention, someone could still use the public information of the call from weweb to Buildship and do the same thing…
Can you please confirm ro correct me ?
This is safe, if you protect your Buildship endpoint.
This is safe, because WeWeb protects your keys.
This is safe, if you set it up properly.
This is not safe to use with private keys, you should route this traffic through a protected Supabase / Buildship / Xano backend.
2 Likes
Broberto gave you the correct answer
You can split backend services in two categories, some are made to be requested from anywhere including a browser, some are made to be used by others backend and so requested from a server, not a browser.
WeWeb is a front end app builder, it will be executed from the user browser, so you must connect to backend services from the first category, the one made to be requested from a browser.
Normally, to be able to connect securely to the second category from a browser, you should connect to a backend from the first category and this backend will do the server-to-server request.
To make it easier for people to built their project on top of popular services like openai and airtable, we made special microservices so they can be used directly in WeWeb.
Theses microservices act as a micro backend in between, it define a restricted list of usable endpoints, and inject the private API Key on the fly so it would never be exposed publicly in the frontend.
The microservice is very simple and naive, it allow people to add easily public data from their Airtable or adding some OpenAI features, but if you want to control precisely who should be able to consume your openai or your airtable data, you have to use a proper backend in between that will handle the access rules.
7 Likes
Lovely explanation! Thank you very much!!
Lets think of a case I also mentioned in the original post: the API call that has to be made to Google Maps API to get predictions in the Autofill function presented in perfect functioning detail here:
The simplest solution I can come up with is: hosting in Vercel the edge function that does the call and trigger it through Supabase and an “Insert” somewhere to avoid exposures. Weweb has a plugin for Supabase, which has one for Vercel to handle variables etc.
Is this the way ?
Another case a bit more complicated would be Stripe
Before I use the plugin for checkout I want to create a new price in my case which cannot be determined before hand and only when the customer initiates the payment process.
How would I communicate with the Stripe API ? If I try to use Buildhsip which does things safely inside of it, as @Broberto mentions, I have an exposed endpoint 
The google map api key doesn’t necessarily require to be protected as google offer multiple way to prevent unwanted usage, you can, for exemple, restrict it to your app domain Panduan keamanan Google Maps Platform | Google for Developers
But yes if you want you can use an edge function, you don’t even need to push it to vercel, you can create it inside supabase and call it from our supabase plugin action Edge Functions | Supabase Docs
I don’t know much about Buildship, if it’s an airtable-like solution we don’t provide a microservice yet to protect the API key so you can’t connect it directly to WeWeb without exposing the api key.
If you manage your users through supabase, you can also create an edge function that will use the stripe API to generate a new price and return it to WeWeb, the edge function will have access to the requester (connected user) to adapt his behavior and confirm the request is valid for exemple so you’re sure the request can only be made by an authenticated user.
1 Like
I believe this is FALSE
Source:
Can someone please confirm so I Leave or Delete this ?
@Alexis i need to fetch data from Supabase into a static collection in Weweb using the REST API plugin. I guess using the service role key (this is needed as some of the table have strict RLS policies), to fetch the data into a static collection is then also not safe right? Was wondering as the data for static collection is fetched from the BE on build time and not on the fly…
Would there be a way to use the Supabase Auth plugin keys within the REST API plugin? I guess those keys are some how encrypted, is it possible to access them?
Otherwise I will create a Edge function (or maybe a Supabase function) to do this… Would just be a bit quicker like this 
Not safe, I encourage you to go with the edge function (or postgres function) way, it seems to be a better way to handle your usecase
1 Like