Logo of AppSignal

Menu
Docs navigation

Parameter filtering

In most apps, at least some of the data that is sent to the application is sensitive or personally identifiable information that should not leave the network. To prevent AppSignal from storing this data the Ruby gem should be configured to not send this data at all or filter out specific values.

Parameter filtering ensures that no passwords or email addresses sent to your application when a user signs in are stored on AppSignal transactions. The same applies to any other data sent with API requests, such as an authentication token.

We support two methods of parameter filtering. If you use Rails, you can use Rails' configuration directly and we will listen to it. If you use another framework, like Sinatra or Padrino, you can use AppSignal's own built-in filtering instead.

Warning: Do not send personal data to AppSignal. If your parameters or session data contain personal data, please use filtering to avoid sending this data to AppSignal.

Table of Contents

AppSignal parameter filtering

This feature is available since AppSignal Ruby gem version 1.3.0.

We support basic parameters filtering directly in the Ruby gem using a blacklist. This parameter filtering is applied to any query parameters in an HTTP request and any argument for background jobs (since Ruby gem 2.3.0).

This filtering supports key based filtering for hashes, the values of which will be replaced with the [FILTERED] value. There's support for nested hashes and nested hashes in arrays. Any hash we encounter in your parameters will be filtered.

To use this filtering, add the following to your config/appsignal.yml file in the environment group you want it to apply. The filter_parameters value is an Array of Strings.

1
2
3
4
5
# Example: config/appsignal.yml
production:
  filter_parameters:
    - password
    - confirm_password

Processor parameter filtering

When some sensitive parameters are still sent by your app to AppSignal, we will filter these out during processing. This means the data was sent to our servers, where we received and temporarily stored this "pre-processing data". We always use SSL to encrypt data moving between your apps and our servers.

AppSignal filters out the password and password_confirmation keys from the parameters during processing. These keys are not customizable. These filtered values are replaced with [REMOVED] (rather than [FILTERED]) to indicate these values were filtered in our processors rather than in your app. Only after this processing, your data is viewable on AppSignal.com. Before that, none of the potentially sent sensitive data is visible to any member of your organization on AppSignal.com. The pre-processing data is removed shortly after processing.

Rails parameter filtering

Luckily Rails provides a parameter filtering mechanism to scrub this data from log files.

AppSignal leverages this mechanism so you can centralize this configuration. Both your logs and the data sent to AppSignal will be filtered with a single piece of configuration.

Filtering specific keys - Blacklisting

There are two ways to determine which keys get filtered. The first one is blacklisting specific keys. In this example the value of :secret in any post in the app will be replaced with [FILTERED].

1
2
3
4
5
6
# config/application.rb
module Blog
  class Application < Rails::Application
    config.filter_parameters << :secrets
  end
end

The downside of this approach is that it becomes more difficult when dealing with larger, more complex applications. Especially when using features like accepts_nested_attributes_for. If we forget to explicitly add keys they will not be filtered.

Allowing specific keys - Whitelisting

If you use a lambda instead of a list of keys you get a lot of flexibility. In the following example we use a lambda to setup a whitelist instead of a blacklist.

1
2
3
4
5
6
7
8
9
# 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

You can have the lambda check against anything you'd like, so you can come up with your own way of determining what needs to be filtered.

Some further information about filtering parameters can be found in the Rails guides about ActionController.

Filter all parameters

To filter all parameters without individual parameter filtering, set send_params to false.

1
2
3
# Example: config/appsignal.yml
production:
  send_params: false

We'd like to set cookies, read why.