Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
101 lines (70 sloc) 4.51 KB
---
title: "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](#rails-parameter-filtering) 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
- [Parameter filtering](#parameter-filtering)
- [AppSignal parameter filtering](#appsignal-parameter-filtering)
- [Processor parameter filtering](#processor-parameter-filtering)
- [Rails parameter filtering](#rails-parameter-filtering)
- [Filtering specific keys - Denylist](#filtering-specific-keys-denylist)
- [Allowing specific keys - Allowlist](#allowing-specific-keys-allowlist)
- [Filter all parameters](#filter-all-parameters)
## AppSignal parameter filtering
-> This feature is available since AppSignal Ruby gem [version 1.3.0](https://blog.appsignal.com/2016/08/29/gem-1-3.html).
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`](/ruby/configuration/options.html#option-filter_parameters) value is an Array of Strings.
```yml
# Example: config/appsignal.yml
production:
filter_parameters:
- password
- confirm_password
```
### Processor parameter filtering
<%= partial "shared/processor_filtering" %>
## 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 - Denylist
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 `[FILTERED]`.
```ruby
# 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 - Allowlist
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.
```ruby
# config/initializers/parameter_filtering.rb
ALLOWED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.freeze
SANITIZED_VALUE = '[FILTERED]'.freeze
config.filter_parameters << lambda do |key, value|
unless key.match(ALLOWED_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](http://guides.rubyonrails.org/action_controller_overview.html#parameters-filtering).
## Filter all parameters
To filter all parameters without individual parameter filtering, set [`send_params`](/ruby/configuration/options.html#option-send_params) to `false`.
```yaml
# Example: config/appsignal.yml
production:
send_params: false
```