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.
- AppSignal parameter filtering
- Rails parameter filtering
- Filter all parameters
This feature is available since AppSignal Ruby gem version 1.3.0.
We support basic parameters filtering directly in the Ruby gem using a denylist. 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
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_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.
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.
There are two ways to determine which keys get filtered. The first one is adding specific keys to the denylist. In this example the value of
:secret in any post in the app will be replaced with
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
accepts_nested_attributes_for. If we forget to explicitly add
keys they will not be filtered.
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 an allowlist instead of a denylist.
1 2 3 4 5 6 7 8 9 # config/initializers/parameter_filtering.rb ALLOWED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.freeze SANITIZED_VALUE = '[FILTERED]'.freeze Rails.application.config.filter_parameters << lambda do |key, value| unless key.match(ALLOWED_KEYS_MATCHER) value.replace(SANITIZED_VALUE) if value.is_a?(String) 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.
To filter all parameters without individual parameter filtering, set
1 2 3 # Example: config/appsignal.yml production: send_params: false