[New Feature] Make API call directly in the browser, if possible

Hi,

I’m having trouble configuring this option. If this option is not checked, the API works normally, but when I activate the API, it stops working. The API has no header or parameter specified. Could anyone help?

Unchecked option:
image
image

Checked option:
image

Up

We definitely need this

1 Like

@gerry98 any news if Bubble will extend this functionality to allow API calls with headers to be made from the browser?

My use case: I’m trying to integrate Supabase with Bubble app in GDPR-compliant way. In this case, need to get my data from Supabase directly client - Supabase server (without running the call through Bubble in the middle).

But in order to access the data, I need to pass the Authorization Bearer token together with the request (token is user-specific, user authorized with Supabase before).

Without being able to make the call from the browser, I’m not able to avoid data leaving EU…
Here’s a quick video of what I’m trying to achieve - Loom | Free Screen & Video Recording Software | Loom

2 Likes

@andriy.bas Javascript to run before your API call:

$.ajaxSetup({
    headers: { 'Authorization': '<your token>' }
});

Warning: This will expose your API key, by sharing it in all client-side requests.

Ideally, use cookies to only include your token in calls to your Supabase domain.
You will need to run this javascript in your Bubble app:

$.ajaxSetup({xhrFields: { withCredentials: true } });

Hey @emmanuel @josh @gerry98, is this feature still in the pipeline? Can you please make it available in today’s pricing scenario? It would be really helpful in minimizing our workload.

1 Like

Is this working flawlessly?

Still no improvement in doing an api call from the browser?
I always get “expected a 2XX statusCode but got 0” when flagged, I tried to recreate the call but no luck.

Still no fix for the ‘expected a 2XX statusCode but got 0’ error message.

@bart @groundbreaker @andyestridge

Did anyone find a solution for the “expected a 2XX statusCode but got 0” error?

This feature still doesn’t work over 3 years later!

@emmanuel @josh

For anyone experiencing the “expected a 2XX statusCode but got 0” error, the solution found by @Jici is to ensure the API you’re using allows CORS requests.

This was what worked for me.

2 Likes

@Jici is the our community’s API guru. I’ve learned a lot from his posts about handling APIs.

3 Likes

I have a question regarding API security:

If I have a backend API flow that uses a user’s API key (secured with data privacy rules) to query external data, and I call my own backend endpoint directly from the browser (providing only the user identifier), is there any risk for the user?

To clarify, the browser makes a call to my backend, which then uses the user’s API key (stored securely on the server) to perform a third-party API call. The response sent back to the browser does not include the user’s API key.

Is this approach secure, or are there any potential risks I should be aware of?

You added a second level of security doing this. If the API key that belong to the logged in user, there’s no need to call the API using backend WF, but this add another level of security. (but cost more WU and slow down thing). The main thing is to set privacy rule so only current user can access to is own key.

The backend WF step is only needed if the user access to another user API data. At this moment, you need to keep the API key for the other user secure.

Finally, don’t forget to set your backend WF to no be available as a public endpoint.

1 Like

@Jici, i understand what you’re saying, but I can’t figure out how to get around this. See, I use a bank’s API to perform financial transactions like Stripe. I can’t set the call with the API key to private because it needs to be dynamic. Every user with a business account has this API key. Up until now, I was making simple calls (like returning the account balance) directly from the frontend, but this was exposing the user’s key to the browser, even though only the user could see it.

My solution was to make this call in the backend and access it via the API Connector, so the key is hidden from everyone, even the user who owns it. As for leaving the WF backend as a non-public endpoint, that way I wouldn’t be able to access it directly via the API Connector, right?

This is not a problem because… he is the owner of the key (not your app…). This user already have access to everything this key give access.

Right. If you use API Connector to call your endpoint, you cannot set this as private endpoint. Take time to read this topic from @georgecollier Why your backend workflows might be your app's biggest vulnerability

Each account is created under the root account, meaning each user with a business account gets an API key for their own account. My concern is not necessarily that he will see the key, but that malware in browser extensions, for example. Shouldn’t I be worried about that?

Maybe I can use the schedule workflow for some cases, except when I need immediate feedback. Thanks, I’ll take a look.

No… and Yes… From my point of view no: it is the user’s responsibility to be careful about what they install. Yes… a third party tool could catch this (but it’s not that simple and this need to be disclosed in extension manifest for example. If the user navigate to a page, a JS script could read the network tab… but only for the current page.) There’s no direct access to the “network tab” or “console” in dev tools.

2 Likes

Example of two calls I make:

1 - payment by credit card - made entirely in the backend, so my user’s client does not have access to their API key.

2 - return the statement - done via the frontend where only the user can view their own key.

In this second example, what I was planning now is to make this call in the backend and use the “return data from API” to read it in the frontend. But in fact, WU consumption increases considerably. My main concern in reality is with the browser, concerned with what the user has installed as extensions. But from what you said, it doesn’t seem to be something simple, I should look for more information about it.

Exactly. And don’t forget that the request is made on server side even if you call it from frontend (you shouldn’t enable call directly from browser if possible because it doesn’t apply for this kind of API.)

1 Like

Forgive me for another question, but why is the call made directly from the server if the user’s API key is not set to private? A simple query in the API service to return the account balance would be done via the frontend, right? I mean, in this example.


If I make this call on the frontend to display the user’s balance, can their API key be compromised? Considering there are robust privacy rules.