How secure is my client-side API Key against malicious extensions?

imad30 · 2024-10-25T21:18:26.611Z

I’m using an application with multiple API calls that rely on an API key from an external service. This key is generated when the user account is created and stored in the database.

For dynamic use, I include the key in the request headers without setting it to “private.” While handling all calls on the backend would be ideal, migrating them would be complex and increase WU significantly.

To ensure privacy, I’ve implemented strong rules that only the current account user can retrieve the API key on the client side, allowing calls to succeed.

My concern is, how difficult would it be for a browser extension with malware to gain access to this API key, given that it is exposed on the client side? Even with strict privacy rules, this exposure worries me.

GH5T · 2024-10-25T23:29:58.200Z

Just hash them. Should be fine.

georgecollier · 2024-10-25T23:31:42.181Z

If the user can access the data through privacy rules, they can access it easily in the browser.

If the API key belongs to that user, that might be fine. Otherwise, it needs to be protected in the backend.

imad30 · 2024-10-25T23:34:32.957Z

But how to send it in the API call, anyway I would have to decrypt it, right?

imad30 · 2024-10-25T23:34:56.105Z

Yes, it always belongs to the current user. It is a business account that uses a payment gateway. But my concern is not about the user itself, but malware in extensions.

GH5T · 2024-10-25T23:36:10.323Z

Correct.

If its a key that can expose your users in any way as far as personal data goes, it’s best to do that in the back-end like @georgecollier had stated.

imad30 · 2024-10-25T23:40:13.209Z

The calls made by my end users’ clients are all processed in the backend, so their clients do not see end user’s key. However, in the dashboard, there are several calls coming back directly from the client, such as account balance retrieval, for example. Migrating all these calls to the backend has been very costly.

GH5T · 2024-10-25T23:45:39.790Z

You might have some optimization to do.

Ideally, you shouldn’t need to “Do a search for” more than once per user, and only need to use it as you mutate. Cache it/store it. Once you have cached the data somewhere, you should refer to that cached data.

When in backend workflows, if you have a big workflow, cache the data inside there, and refer to that.

Bubble

Templates for Bubble

Buy and sell Bubble templates to speed up app development. Bubble is a visual programing language that lets you build apps without code.

I use this to store data in the backend and refer to it when I do backend workflows. Rather than searching more than needed.

Then for front-end, return that data back from the server once on page load or whatever, and save it as a state. only update it as necessary.

These two methods alone will optimize your querying by A LOT.

I don’t care what Bubble says, their caching system is … “non-existent”.

imad30 · 2024-10-26T00:28:55.798Z

I really appreciate your suggestion. I might implement this in my database queries to optimize my app, since I didn’t know about this plugin you sent, thanks!

As for the API, since I need to query the gateway in real time, Stripe style, I think the best way to do this would be to move it to the backend.

But if I knew that the only risk with the current method would be with the user, that would be less of a concern.

My main concern is with extensions, since Bubble runs in browsers, and extensions give access to a lot of inappropriate things.

GH5T · 2024-10-26T02:17:59.663Z

As long as you state somewhere in your terms that you’re not responsible if they have had their information leaked via their own doing (like installing an extension), you should be fine.

The key concern is the fact that the user only has access to their own information.

imad30 · 2024-10-26T02:30:46.711Z

I was thinking exactly about this. I implemented robust security improvements regarding transfers, for example. Not even with the API key would someone be able to make a withdrawal. Now, regarding the other information, in case the user does not pay attention to this type of concern, I thought exactly about exempting myself in the terms of use, thanks for the help.