Hello,
I just noticed that the API key is included in the web page code (anybody could hack our backend) and cannot be encrypted (is this meant by encode?). I can encode the Get Record and Update Record URL placeholders. This is a critical issue. How can I make my app safe?
Thanks for answering this soon.
Kind regards,
Bert
By chance I found a similar question (thereās no solution so far): Ninox Database - Thread / Optain Bearer-Token Client-Side?
I found a possible solution: Pipedream. But Iām not familiar enough with this tool to create a working workflow. Any expert out there? I would also pay for assistance.
I am afraid you are mixing things up here.
- including the API-key in the url is standard and thereby accessible by anybody. The API-key is not meant to secure data.
- āencodingā is not anything similar to encryption. You can find the information e.g. on wikipedia here: Percent-encoding - Wikipedia
- securing your data needs to be done in your backend configuration by setting the āsecurity rulesā. In case you are using firebase for the backend, you can read about its security rules here: Firebase Security Rules Ā |Ā Firebase Documentation
- Passing the bearer-token in the header of a http request will identify the user. If this is required to retriebe data depends on the āsecurity rulesā of your server.
2 Likes
Hi,
Thanks Pipedream I could resolve the issues in the meantime. I also found the definition for āencodingā in the meantime and could apply it. Of course I could have used basic authentication (user name/password) but for our purpose this would be too complicated and isnāt required either.
Kind regars,
Bert
@Bertrand_Gillert Sounds like you got the answer but if you want more info on security in your apps, we have a general primer on the topic 
Thanks so much for this clarification! Iāve been tearing my hair out a bit wondering why there werenāt better tools for hiding my api keys included in these no-code apps, but when you explain it like that it makes way more sense why theyāre so chill about it.
To clarify for my peace of mind, youāre saying that itās ok to explicitly set the authorization headers of your REST API requests to a regular Bearer token like the ones provided by Airtable, for example, because data security is handled on their end with access rules somehow? It seems like anyone who can see my api key can fire a curl to access my airtable data, right? Iām a little confused on how that works. Maybe I need to dig deeper into that part of the airtable docs?
Iām not familiar with Airtable, therefor I will describe it for firebase:
- On sign-in the user receives his/her Bearer token. The token is valid for 30 minutes. The token is stored in an app variable.
- In order to get data, the user sends a HTTP request, which includes the static API and the current Bearer token.
- The backend checks, if the security rules allow to respond with the requested data. The rules were defined by yourself beforehand (e.g. users need to be authenticated (with a bearer token), users may only read but not write in a certain collection, ā¦).
The airtabe docs should explain how to define the security rules for your project.
Beautiful! That makes total sense. Youāre referring to a temporary bearer token obtained through Firebase auth, but airtable provides a static api key that it instructs developers to hide in a directory external to the source folder, as does Google in several docs Iāve seen for other similar keys. However, there is also an option to utilize an Oauth flow, which is more secure, but I think requires me to authorize users to access that part of my app. I think thatās a manageable task since Iām mostly just putting together a demo of my app development stack in the process of building it. Thanks again.