My retool account has a number of API keys, username/password pairs, etc. stored as secret configuration variables, and I'm used to seeing the "---redacted-sensitive-value---" line show up in logs and such while working with these values, but recently I've encountered a frustrating situation where I'm reading data from an API, then using the response data in a call to another API, but that response data includes strings which partially overlap with one or more of our secret configuration variables, and retool is injecting "---redacted-sensitive-value---" into the data, not just in the workflow editor's UI, but actually in the execution of my code, interfering with my call to the 2nd API.
Thankfully, the issue only seems to occur when running blocks individually, if I run the workflow as a whole the redacted text doesn't make its way into my API calls, but it's still a fairly annoying limitation, as running blocks individually is an important operation during development and troubleshooting of new workflows.
I'm not the first to encounter issues with this:
In those threads the posters just stopped using the secret config vars to sidestep the issue, which seems reasonable in their use cases as the offending 'secret' value's didn't appear to truly need to be secret, but I think this issue merits further consideration.
In my case, the offending secret is an username or password, which happens to overlap with part of some URLs we're reading out of an API resource (they overlap because they both reference the name of an associated organization), which we then submit to a different API. So if I run my code one block at a time for development reasons, the url's arrive looking something like this: http://---redacted-sensitive-value----api-org.some-url.com with the original being something like http://my_secret_value-api-org.some-url.com
Obviously I can resolve this issue in a few ways, and I'm not expecting an immediate solution from retool on account of this fairly minor inconvenience. But this really feels like a defect in need of fixing: the data is coming from an external resource, there's no reason for retool to be redacting it, much less using the redacted version as input to my workflow blocks. The blocks don't even reference the secret variable, they use a custom API resource which in turn references the variable in it's auth procedure, but the variable is never directly referenced in this workflow.
Plus, from a security standpoint, scrubbing the secret value out of a larger string like this actually reveals information: if someone saw the unredacted URL, they wouldn't have any reason to think a portion of it is being used as a username/password somewhere, but if they see the redacted URL they know it definitely is, and they may be able to deduce the exact value of the redacted portion by inference - knowing what characters are permitted in that section of a url, and how the host website tends to generate org-level subdomains could narrow the search space considerably.
I can understand where this issue comes from and how a fix might be quite difficult to reconcile with legitimate security goals, so any fix is likely to be slow to release, and the limited impact of this defect might not justify the expense of fixing it at this time. But, I feel like it should be discussed a bit more thoroughly, and perhaps some additional visibility should be given to the issue in documentation to help developers plan around it.
