My API connector calls are publicly exposed

Hi,
I have set up certain API calls to QuickBooks via the Bubble API connector. The calls are not via backend workflows. All the calls have auth bearer token that goes into the header. Example of he call below -

Now the problem is - We got our app reviewed by third party, and they checked it through Burp Suite and found that critical info is exposed without any authentication.
Anyone can go to this link - mysite/api/1.1/init/data?location=[my dashboard's URL] and can see the details of the users including the tokens.

Am I doing something wrong?

EDIT - This is the data that you can access by going through the URL

1 Like

The authorization key must been private.

1 Like

I cannot make the auth key private because this is user-specific and I need to pass the value of the bearer token while making the API call.

I’m not 100% sure if I understand what is being exposed, but you can keep the Authorization field non-Private and just remove the Bearer token you used to initialize the call.

the calls are proxied with a server. if you mark parameters as private they stay in the server and are never exposed to the client. you can use the api connector in a client workflow or a backend workflow. in a backend workflow everything stay on the server. if you need the auth token to be dynamic but you don’t want to expose it to the client then you need to use it on a backend workflow only.

of course you need to consider where are you storing the token and what measures youhave in place to limit the access to the data

1 Like

I’m sorry, but I’m no sure if I understood properly. Are you talking about the API resposnes? I have edited the post to add more info.
To me, it looks like that the API call between Bubble’s FE and BE is being exposed.

I have updated the post with more info. It seems that the API cal between Bubble’s FE and BE is being exposed.

As long as you have the API Call in a client workflow and set the key to public it will be exposed to the client.

Like @dorilama said, the key is exposed because it’s no set to private, but if this is user related (current user key) it’s not a problem because this info is already know by the current user. And the call is made server side and not client side. But be sure to have privacy rules applied to this field so only current user can see it. If you want to totally protect key, the workaround from @dorilama is the way to go.

3 Likes

Thank you. I just checked the privacy data rules and found that it was set that “Everyone Esle” can also see the data. Changed it and resolved.

1 Like

The autorization key of the API connector will still be visible in the client code in the browser.

But it’ll be visible only to the current user, right? If yes, then it’s fine as it’s user-specific.

No the key will be visible to everyone.
Here a note from the documentation:

Note that even though by default, API calls are made from the server, a description of the call is sent to the browser and are thus visible to a savvy user. This means that any sensitive parts of the call, especially secrets / tokens, should be in fields marked “Private”.

But how can it be visible to everyone? During the API call, the key is picked from the current user’s data in the database. So only the current users can see that value.

Ah ok I got it. Then it should be secure. But you should ask a security expert. Because the key will be send through networks.

Keys are always sent to network even if private. Https need to be used. Better to use it in header. This is done here. The best would be to use oAuth2… but it’s not always available.

1 Like