Security concern about exposed token 🍳

Baserow Help
1

Having successfully connected my no code dev tool to my baserow database via rest API (I get the right API call response, now ready to fetch the whole schema), I see in the dev tool that the full header with the token is publicly revealed.
image

Is that normal and is there a workaround, please?

1 Like
2

Hi @Fred, this is normal. The token has to be transferred to Baserow servers, otherwise it wouldn’t know that its you!

The important thing is that the connection to the server itself is secured via SSL (so the requesting address starts with https:// (note the s). When this is the case, data between the client and the server can’t be accessed by third parties as the whole request is encrypted.

Then if you don’t expose this token in any other way it is secure. So make sure the token itself is not leaking/being displayed anywhere.

3

Thanks for this explanation.
Question remains: by exposing the “login” info to the API, can any malicious user CRUD the data since I have this setting?
image

4

It all depends on what you mean by “exposing”. The communication between the client and the server will be secure over https, so the security now lies on the client. Generally speaking, if the client is another backend application that is itself secure, no problem. If the client is a script/code that is being invoked from the browser or from a user directly, then the token will be exposed. The token permissions have nothing to do with whether the token is/can be exposed.

If you are concerned about other Baserow users that you have in the workspace, then any user that can create/work with tokens for the particular database can also use these tokens. Is this what you meant?

5

Thanks Petr for taking care of my concern.
Issue is not with other baserow users or registered/authorized users of the app I’m planning to build with no code tool Appgyver, but with malicious attackers (not registered user) who could use the exposed token to read, update, delete data since the API has full CRUD ability.
In hindsight, I don’t see how the https addresses my concern.

6

Well, if you create a powerful token then anyone that gets access to it can indeed do intense damage. HTTPS makes sure the token is not exposed over the network itself from the API user (that is some sort of client application) and the Baserow server.

Where/how do you use the token? I am not familiar with AppGyver, but I assume that it will generate an application from which this token needs to be used? If that’s the case, your concern about embedding a powerful token like that is pretty valid.

I’d say that for apps like this that will run on devices/servers you don’t control it is better to authenticate users based on their own credentials and use time-limited JWT tokens. In this case any user that would be authenticated will have their own token, with permissions set to them directly.

We plan to introduce better access control in the near future so we are happy to hear about any permission-related wishes you might have.

7

The app builder is browser based, the token gets exposed when I do the REST API integration and fetch the schema. The future product will be a webapp and a native app published on the google and apple app stores. Maybe I worry too early and the token is actually not exposed when the webapp is running with un/authenticated users?

Side question. How do I fetch data of all tables in the database (id 28742)? All I see in the doc is how to fetch data from specific tables, fields, rows…
(eg: https://api.baserow.io/api/database/fields/table/64749/)?

8

Yeah so in general for the answers what happens with the token you need to ask folks from AppGyver. But this token you have should not be just distributed to individual apps that don’t run on your server, for that you should let users authenticate and use a temporary user-specific token.

Side question. How do I fetch data of all tables in a database?

Do you mean a list of tables or do you want to just get all rows from all tables of a workspace?

9

Two types of users:

  1. Buyers don’t auth when browsing the catalog which is public. Yet the app needs to use some token credentials to access and publish the data, right?
  2. Service providers do CRUD ops to create an account and publish services, so app needs to use a specific token for such ops. It’s where temp user-specific token comes into play - any doc about how I do this?

Yes, all, no table-specific, in a json format.

10

In general, you can use Baserow as your user management system, then an authenticated user will have their own token to perform operations in Baserow. Or - you will need a separate auth backend that will authenticate and authorize users and this backend could use a permanent token to perform operations in Baserow.

As for getting all data from all tables in a workspace, you can for now list all applications in a workspace and then iterate and fetch data from each database application. Not sure if we would be adding an endpoint to fetch data from multiple tables.