We have found quite a bad security issue with the public apps where an unnecessary amount of data is exposed through an endpoint.
In the case that you are logged in and you open public app on the public url, you can inspect the page and look at the network, and you'll see a API request called "user" and it returns a response where it includes every single user in the organisation and all of their personal details as well as a lot of unnecessary data (even people who have been offboarded from the organisation) - it basically returns all of the information about the Retool organisation to whoever is looking at this (including all apps created, all organisational settings and more).
It also includes the billing contact, the credit card details of the organisation if you are a admin.
It seems this is limited to public apps, it does not hit the same endpoint when you are looking at a logged in app.
I believe you're testing this from a non-incognito window which still has a valid org token in storage from your logged-in session and is still capable of hitting this endpoint.
If you try this in incognito, it shouldn't call this endpoint!
^ this is non incognito
I see, thank you! I guess the thinking is, why is all this data necessary on this page?
Even if I am logged in as a user - when I am on a normal app, it doesn't seem like this end point is hit, so just a bit weird that when I am on a public app, it hits this end point (in the case that I am logged in) and returns all the user data in the organisation, when that data isn't really necessary on this page
We also logged out and we logged back in as a user (who is not an admin), and it still hits this endpoint and returns all the users in the organisation as well as a lot of the organisational settings - which for a normal Retool user seems a bit strange to return all this information to them
I don't think all of the data is used in every place, but the endpoint returns useful data for a lot of different contexts. It probably stems from the Retool Embed feature which uses logged-in sessions, or the ability to embed public apps in an iframe if unable to use Retool Embed for a use case, which allows users to access org-level features such as Retool Storage which would usually not be available without this token.
