Most of our customers work with sensitive data, which may not be shared with anyone outside of their network. When adding AppSignal to such an application, we need to be extra careful about which data to send.
Rails - Filter Parameters
we never send any of the request parameters that are added to the Rails filtered params.
In the example below,
if the key
secret is found anywhere in the request parameters,
its value will be replaced with
1# config/application.rb 2module Blog 3 class Application < Rails::Application 4 config.filter_parameters << :secrets 5 end 6end
This example shows the default way to sanitize the request parameters.
By adding items to the
filter_parameters array we create a blacklist
with keys that need to have their values filtered.
By being explicit,
we can ensure a more secure log file.
The downside of this approach is that it becomes more difficult when dealing with larger,
more complex applications.
We could allow users to fill in
accepts_nested_attributes_for and a nested form.
But if we forget to explicitly add this new key,
it will not be filtered.
With a little work though, the parameter filter can be changed into a whitelist:
1# config/initializers/parameter_whitelisting.rb 2WHITELISTED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.freeze 3SANITIZED_VALUE = '[FILTERED]'.freeze 4 5config.filter_parameters << lambda do |key, value| 6 unless key.match(WHITELISTED_KEYS_MATCHER) 7 value.replace(SANITIZED_VALUE) 8 end 9end
By modifying the whitelist to allow more values, you can pass more parameter values to both your log files and AppSignal. This puts you in total control of which params go over the wire (your CSO will love us for it).
In the second post about sensitive data we will cover how the AppSignal gem sanizites queries and how you can sanitize data in custom instrumentation.