You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rails' filter_parameters system is used by e.g. Rails logging and error notification APIs like Airbrake to avoid sensitive information leaking out. It works by running over a hash and overwriting it for certain keys. However, Grape puts the entire request body in env['api.request.input'] as a string, which means the param filtering doesn't operate on it. This can lead to e.g. plaintext passwords getting logged in error catchers.
This can be solved by adding 'api.request.input' to filter_parameters in Rails application configuration. Should I adapt the documentation to warn people about this, or should we look for other ways to avoid this behaviour?
The text was updated successfully, but these errors were encountered:
I think a solution has to be built into Grape for this and set on Grape's config since it effectively has it's own mechanism for routing and everything.
Any update on this? I've noticed we're seeing sensitive auth tokens being stored in our logs. We had filter_parameters working before implementing Grape.
Rails' filter_parameters system is used by e.g. Rails logging and error notification APIs like Airbrake to avoid sensitive information leaking out. It works by running over a hash and overwriting it for certain keys. However, Grape puts the entire request body in env['api.request.input'] as a string, which means the param filtering doesn't operate on it. This can lead to e.g. plaintext passwords getting logged in error catchers.
This can be solved by adding 'api.request.input' to filter_parameters in Rails application configuration. Should I adapt the documentation to warn people about this, or should we look for other ways to avoid this behaviour?
The text was updated successfully, but these errors were encountered: