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

By design, 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 [FILTERED].

# config/application.rb
module Blog
  class Application < Rails::Application
    config.filter_parameters << :secrets
  end
end

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 :big_secret_attributes somewhere, using 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:

# config/initializers/parameter_whitelisting.rb
WHITELISTED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.freeze
SANITIZED_VALUE = '[FILTERED]'.freeze
 
config.filter_parameters << lambda do |key, value|
  unless key.match(WHITELISTED_KEYS_MATCHER)
    value.replace(SANITIZED_VALUE)
  end
end

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.