The resources endpoint (/api/resources) is called any time you open the app and all data related to the resources are available and not obfuscated or sanitized, even though we clicked "sanitize" (see screenshot). The endpoint lists all resources of our account with token, api keys, etc available to anyone, which is clearly not secure.
Console log
Sanitize check
Are you aware of this issue?
Thanks for flagging this, @Vincent_C! Data security is obviously an important requirement. I've asked our team here to review everything that you've described here.
In my own brief testing, it seems that all inherently sensitive data relevant to the configuration of a built-in resource - access tokens, API keys, passwords, etc. - are properly sanitized:
I can confirm that custom headers are not sanitized, however, and imagine that the same is true for custom URL parameters.
It does look like this endpoint respects permissions groups, though. It's really only relevant for customers on the Business plan or above, but the server only responds with information about a given resource if the user has access to said resource.
As mentioned above, I've pinged our security and governance teams to get their eyes on this and will provide an update here as soon as I can! Thanks again for reporting. 
Hi Darren, thanks a lot for the quick answer.
Each individual resource request do respect the sanitization option. I can see that too.
However the issue is coming from the "/api/resources" endpoint that is triggered when the app opens and literally lists all my resources configuration. Everything (URL, headers, name, body, etc) is exposed in the API response and I can see it all via the developer tool.
Hope it clarifies a bit more the current issue.
The screenshot I shared above is from the /api/resources response, as well! There seem to be certain fields that Retool knows to sanitize by default - typically authentication credentials for any built-in resource. Do you have any resources authenticated with OAuth2, for example? Can you double check to see if the oauth2_client_secret is obfuscated in the response payload? It definitely is for me.
For the time being, the biggest issue that the team and I have identified and prioritized is ensuring that the /api/resources response respects the "Sanitize custom headers" setting. I'll let you know when that update gets pushed out and additionally keep you in the loop with regard to any other issues we identify!
Thanks Darren.
I confirm oauth data are obfuscated, which is good.
We're aligned on next step regarding the "Sanitize custom headers" setting, keep us posted!
