-
-
Notifications
You must be signed in to change notification settings - Fork 22.8k
Sanitize sensitive fields in request header and body in logger #5279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
const requestMetadata = { | ||
request: { | ||
method: req.method, | ||
url: req.url, | ||
body: sanitizedBody, // Use sanitized body instead of raw body | ||
query: req.query, | ||
body: sanitizedBody, | ||
query: sanitizedQuery, | ||
params: req.params, | ||
headers: req.headers | ||
headers: sanitizedHeaders | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
# LOG_PATH=/your_log_path/.flowise/logs | ||
# LOG_LEVEL=info #(error | warn | info | verbose | debug) | ||
LOG_SANITIZE_BODY_FIELDS=password,pwd,pass,secret,token,apikey,api_key,accesstoken,access_token,refreshtoken,refresh_token,clientsecret,client_secret,privatekey,private_key,secretkey,secret_key,auth,authorization,credential,credentials | ||
LOG_SANITIZE_HEADER_FIELDS=authorization,x-api-key,x-auth-token,cookie |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How this will be deployed in the Flowise cloud?
How this will be communicated to Enterprise customers?
# DEBUG=true | ||
# LOG_PATH=/your_log_path/.flowise/logs | ||
# LOG_LEVEL=info #(error | warn | info | verbose | debug) | ||
LOG_SANITIZE_BODY_FIELDS=password,pwd,pass,secret,token,apikey,api_key,accesstoken,access_token,refreshtoken,refresh_token,clientsecret,client_secret,privatekey,private_key,secretkey,secret_key,auth,authorization,credential,credentials |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you compile this list? How to validate is there any missing field?
Uh oh!
There was an error while loading. Please reload this page.