I understand that we can restrict data returned from the server via privacy rules, but if I expose the data api for a certain Type, Bubble will still return a success response if any random person sends a request to that “Type’s” endpoint (even if there are no results sent back).
This doesn’t feel great as a developer. It feels like our app is less secure than it should be. What I’d love to see is a 400 error of some sort sent back. Is there any way around this?
I understand. Data API doesn’t have the same option for authentication. You should add this to the ideaboard.
About workaround, the only thing I can see is to deactivate data API and only use Backend WF. But it’s probably better to stay with Data API even if there’s no option for authentication.
@Jici Thanks for the response. Yes, definitely need to stick with the Data api in my case.
@allenyang I don’t know if it’s just me, but this feels like a massive oversight in regard to security that needs to be addressed, rather than a feature request to add to the idea board.
If you enable the Data API for a data type, it allows users to easily get any Thing that privacy rules permit them to. If your privacy rules do not permit a logged out user to see the data, they’ll see nothing. There’s no security benefit to returning an error if the user is logged out / there are no results, and it makes it harder to deal with as a developer.
@georgecollier Because why is any person on the internet able to access my app’s API if I don’t want them to?
A success response tells a user that “Yes, this endpoint is available to hit.” I don’t want anyone to know that. It’s revealing way more information than I’d want, and I feel naked.
You would never do something like this outside of Bubble. Why is it the case in Bubble?
Furthermore, there is a lot of info returned in that response that gives hints about how the endpoint works (cursor, count, remaining). If someone were really trying to do some damage and find other endpoints that I may have messed up privacy rules for – it wouldn’t be too hard to figure out how to pull all the data out. And yes, I know that’s the developer’s responsibility, but it feels like a success response in this case just reveals way more than it needs to about one’s app.
Because you allowed them to, by virtue of enabling the data API. If you don’t want them to, disable the data API. You can create a backend workflow if you want that will accomplish the same thing as the data API (though your backend workflow will also be public so what’s the point?)
If you have privacy rules, the data is secure.
I cannot emphasise this enough:
Privacy rules are the only thing that protect data visibility in Bubble. No matter if your data API is enabled/disabled, backend workflows exist/don’t exist… any data permitted by privacy rules is accessible.
@georgecollier I get what you’re saying, but I think you’re missing my point.
Regardless of the fact that data is secured by my privacy rules, I don’t want Bubble’s system to respond to API requests from any random person that shouldn’t have access to that data with a success response. In my opinion, this reveals much more about how my backend works than it should.
I only allowed them to because Bubble is forcing me to in this case. On a backend workflow, I have the option to enable an endpoint to be hit with or without authentication. If any unauthorized user tries to hit that endpoint, they get an unauthorized response. Why can’t I have that same response for unauthorized requests to the data api?
How will I get the Data API response for a logged out user so that I can return the data a logged out/unauthenticated user should have access to? Requiring authentication makes that impossible…
Suppose I use the data API to show some data on my home page for some reason… the data API returns data that the current (logged out) user should see. I don’t want that to error do I?
It’s an unavoidable fact that Bubble does make public a lot about how your app works. But even if it made nothing public - obfuscation would still not be sufficient for security. Whilst it helps (marginally), proper app security practices are what safeguard your app and data.
Just to clarify - when you require authentication, all this means is that the person calling the backend workflow should be either logged in, or using an admin API token. If anyone can create an account and login to your app, then blocking runs without authentication is pretty futile as they can still just create an account and hey presto, they’re authenticated.
More than that: That the endpoint exists, that I’m hitting the endpoint exactly how it’s supposed to be hit, and that there is a response object containing cursor, results, count, and keys fields.
I’m not sure I fully understand you here, but I think you’re asking about how a logged out user will still be able to have access to data you want them to have access too? (Correct me if I’m wrong)
If that is what you’re asking about, then I think basic privacy rules would take care of this?
All I’m saying is that if the"results" array in the data api response is an empty array–and if it’s an empty array BECAUSE privacy rules are preventing data from being returned (rather than it being an empty array because there isn’t any data for that query)–then Bubble should return an unauthorized response rather than a success response like it currently does.
If there’s data you want anyone to be able to see and someone hits the data api, then of course it makes sense for that to be returned. But I think we’re just talking about basic privacy rule stuff here?
EDIT: Scratch that – I think I understand what you’re saying. See point below.
You’re right, and this is a good point. And in this case, we still fall back to privacy rules. So I guess if Bubble MUST expose these data endpoints to any unauthenticated user because of how their system is designed, they will still know if an empty array of results is returned from the data api because the user is unauthorized to see that data – and in those cases, I’m arguing a 400 response should be returned rather than a success response.
That will at least prevent any Joe Schmo from hitting a data endpoint and seeing exactly what a success response looks like from the backend of any Bubble app.