Security Questions

I have some general questions about WeWeb, and how it is working under the hood so that I can understand how to secure an application. Basically, I’m just trying to understand what is happening with the data at different stages. These questions will help me.

  1. What is happening with the data that is being sent back from the API call, and is it secure?

Basically, what I am wanting to know:

  1. If I have a collection that queries an API that sends back records, and I only want the user to ever be able to see records that belong to them, is this secure inside of WeWeb? … The filtering that is done, is that preventing someone from ever getting access to records that are not theirs?

  2. If items are stored in a variable, are those records available to any user that knows how to look for them? or are those variables kept on the server?

I know that’s a lot so I appreciate any insight.

2 Likes

Hi @kevinwasie :wave:

Great questions!

What is happening with the data that is being sent back from the API call, and is it secure?

First thing to know: the data that is sent back and forth between WeWeb and the API is done with HTTPS. WeWeb will not allow you to make HTTP requests.

Second thing to know:

  • if you are using the REST API plugin with a static or cached collection, the data is stored on our servers
  • if you are using the REST API plugin with a dynamic collection, the data doesn’t even go through our servers

If I have a collection that queries an API that sends back records, and I only want the user to ever be able to see records that belong to them, is this secure inside of WeWeb? … The filtering that is done, is that preventing someone from ever getting access to records that are not theirs?

Using the REST API plugin, If you are:

  • filtering the current user information at backend level,
  • using an authentication token (as opposed to a basic user id or email address for example),
  • getting the data from a secure API,
  • using a dynamic collection,

then yes, the authenticated user will only be able to access their own information.

In other words, if the filters are correctly set at backend level so that you are only getting the information you need, then other users won’t be able to get this information.

For extra security, you can limit access to the page where the information is displayed to the current authenticated user.

Things to keep in mind:

  • if you load more information than you need in the frontend, all that data may be accessed
  • if you are getting data from a tool that doesn’t have best-in-class security, your data is vulnerable
  • if you are using a user id or email address to filter the data instead of an authentication token, someone could potentially make the API call for the user id or email address they want.

If items are stored in a variable, are those records available to any user that knows how to look for them? or are those variables kept on the server?

The default values of your variables are accessible on all pages of the frontend.

You should not have any variables where the default value is sensitive data.

If you have a workflow in the project that updates a variable and you are using the REST API plugin to update the database, the data will not even go through our servers.

Does that help?

Don’t hesitate to reach out again if anything is unclear :slight_smile:

2 Likes

UPDATE

We just released an option to make server-side requests when using the REST API plugin.

By default, being a frontend builder, WeWeb will make client-side API calls. But because many REST APIs only accept server-side calls, we built a feature that allows our users to make server-side calls if they need to.

When a user enables that option, WeWeb will make the request via a dedicated server, without saving or looking at the data going through this server.

Another solution is for users to contact the API admin to allow the “weweb.io”, “weweb-preview.io”, and the domain of their published project to make client-side requests so that client-side requests from the WeWeb Editor, Preview, and Published project go through.

3 Likes

Hi Joyce! Thanks for the explanation, I was actually just taling to Rapaël about this.

Could you perhaps elaborate on how to go about this? Specifically the filtering on the backend level and how that would look both at the backend (Xano in my case), but also the frontend. Would this mean creating a sort of role for every user individually in WeWeb? (I hope not haha). What would be best practice?

I think the calling and editing of data personal to the user individually is a major use case, since this is what almost every web application does from LinkedIn to Tinder.

Thanks in advance for your kind help!

2 Likes

Hi @kai it would mean making an API call in the frontend that only fetches the current user in the backend.

In Xano, that would mean creating a new endpoint that sends back filtered data based on the user input as described at the beginning of this video.

In WeWeb, it would mean creating a new collection using that new endpoint so you’re only getting the data related to the current user.

Does that make sense?

I’ll try making a tutorial this week to walk you through this step by step :slight_smile:

Hi @kai,

As promised, here’s a step-by-step tutorial on how to get the current user data from Xano in a secure way, i.e. with an API endpoint that requires authentication, using an auth token (instead of an email address for example) to identify the current user.

Does that help?

1 Like

Hi Joyce! I found your step-by-step tutorial very helpful.

In other words, if the filters are correctly set at backend level so that you are only getting the information you need, then other users won’t be able to get this information.

I’m trying to only allow users to access/read/edit/update data in Airtable that belongs to them. Reading your comment in the context of Airtable, however, makes me think setting role based access controls to Airtable data as not possible because you can’t set these filters in the back-end. Is that a fair statement?

Of course, the exception would be creating different Airtable views in each table for each user, but that’s not realistic.

Hi Wes!

It’s possible, but not the most secure.

For example, you could allow a user to only update the data that is linked to the email address they authenticated with. However, another authenticated user could “hack” the API call and access their data if they guessed the email address.

To add a layer of security, you could create a unique identifier that’s very hard to guess and use that as the linked field in Airtable so the user’s email address would only be accessible in your authentication system (WeWeb Auth or Auth0 for example).

Still, it would not be as secure as working with a state-of-the-art backend (like Xano or Supabase) that allows you to secure the API endpoint and filter the data before it reaches the frontend.

Does that make sense?

1 Like

For example, you could allow a user to only update the data that is linked to the email address they authenticated with. However, another authenticated user could “hack” the API call and access their data if they guessed the email address.

That makes sense. Thank you for clarifying this.

To add a layer of security, you could create a unique identifier that’s very hard to guess and use that as the linked field in Airtable so the user’s email address would only be accessible in your authentication system (WeWeb Auth or Auth0 for example).

Could you clarify this a bit?

Would Auth0 have to have that identifier in its system? If so, would Auth0 <> Airtable have to communicate via an API or webhooks when the user is added (in this case, to Airtable) to make sure they both have that identifier?

Yes, exactly. You can create an automation so that when a user signups via Auth0, Airtable is updated with that info.

1 Like