Even with redaction, logging HTTP request bodies, params and query strings is generally a bad idea because it significantly increases the risk of accidental exposure of sensitive data due to misconfigurations, broken redaction logic, or logs being improperly secured. It also creates a massive compliance burden under regulations like GDPR and CCPA, as these logs can inadvertently capture Personally Identifiable Information that must then be managed and defensibly deleted.

Recommend either removing body, params & querystring from here or putting them behind a log level so they're only captured when debug logs are enabled.

btw, apologies if this changes the requirement from what's on the Jira. The Jira's wording was based on the documented findings. Now that I'm seeing the code and not just the finding, I think the finding's recommendation was not in line with how Workday generally treats areas where sensitive data could slip in. Omitting these specific bits on production request logging is standard practice.

Got it. I'll put them behind the debug log level so the headers, body, and querystring are not logged. They won't be logged in production since we've use the default info.

How this will be deployed in the Flowise cloud?
How this will be communicated to Enterprise customers?

This will not be deployed in Flowise Cloud, since we don't want to log headers, body, and querystring. And we've set the default log level to info so there won't be a need to set these variables for Flowise Cloud.

How did you compile this list? How to validate is there any missing field?

I just wrote down commonly used keys for sensitive information and their different variations. Since we can't know ahead of time what data will be sent in headers, body, and querystring, it'll be the open-source/enterprise customers' responsibility to configure it based on their requirements.