2 - I need to evaluate whether a user has been failed logged in several time before they log in, if I disable everyone else to see the “log in failure count“, the workflow won’t be able to
I see! I’ll move the login check to backend workflow.
But regarding the current user’s information point, it’s actually returning the data of what ever the ID I passed into this url. As shown below, first screenshot is when I pass user ID, and second screenshot is when I pass a transaction ID.
I didn’t get what you mean here. since the security check is pretty strict, less data show here may be better. For email, I can set in the privacy rule to hide it, but I don’t think I can hide “user_signed_up”:true in the privacy rule.
If you have the user ID, you know they’re signed up, don’t you?
If you don’t have find this in searches enabled, people can only find a unique ID by guessing, and that’s near impossible. And, if they do guess it, there’s not much they can do with it other than know an item with that ID exists.
This seems related to the Bug I raised a few days ago.
When testing and trying to understand what was the cause of the protected data remaining visible after logout and using browser back button, I saw a lot of stuff about the init/data.
There was some help in understanding, but nothing that was definitive. It was hypothesized to becoming from the BFcache, but from testing it was coming from http ‘memory disk’ cache, which as far as I can understand, those two are different. ChatGPT was helpful in helping me setup some tests to uncover exactly what was going on and it seems Bubble is allowing private data to be cached if a page has a content type, or if a search uses a unique ID in the URL path list item #2.
I know the reason for the private data remaining accessible even after logout is different from how you are seeing private data available as you are doing a direct api call to the init/data. I just mention what I saw as during the testing I could see that same api call running and recall it as suspect when navigating back to the protected page after logout.
Try reaching out to Bubble support. They likely have a web security expert that could look into it. I imagine if you are doing this for a the purpose of a security review, and the review failed because of this issue, whoever did the review is likely a qualified and experienced web security expert with some deep knowledge on a subject like this.
I was trying to figure that out for the bug I was dealing with. ChatGPT suggested intercepting the api call to attached headers to it so as to force it not to cache the data.
Out of curiosity, are you experiencing this on a page that has content type set on it, so as to use the ‘current page thing’ in dynamic expressions on the page?
Yes, I understand it doesn’t return data the user can’t access. However the security review has been strict—we’ve been marked unqualified multiple times. They still haven’t confirmed whether returning {"authentication":{"email":{}},"user_signed_up":true} is acceptable yet. Hopefully this is fine but the safest is to return .
Well, any security reviewer shouldn’t find an issue with an intentionally public endpoint that only returns data that the user has access to Hope you can get through it
Just heard back from the security review team—unfortunately, this doesn’t meet the requirement. The endpoint should return a 404 or 400 error when no data is found, rather than the current behavior.
Would appreciate any help or suggestions on how to address this! Thanks in advance.
That’s awfully pedantic of them. There’s nothing insecure about returning a 200 rather than a 4XX so long as no data is returned. They’re wasting your money.
Hope you can get through it