Filter request parameters

Every time a request is made on your application, AppSignal collects the parameters sent with that request. This includes form data (POST), query parameters, and keys in routes (e.g., /user/:id/) in some frameworks.

This data could contain user-identifiable information such as names, email addresses, passwords, two-factor authentication codes, API tokens, etc. To protect your application's sensitive data, you must ensure this data is filtered out before being to the AppSignal servers. This way, your application doesn't leak any sensitive data.

Read more about parameter filtering in our Parameter Filtering documentation.

Your application should not collect user-identifiable information (such as personal names, email addresses, passwords, etc.). Use the tools described in this guide to limit and filter out this data.

Parameter Filtering

Basic parameter filtering in the AppSignal integrations works with a denylist, a list of keys to filter out and to not send. You can set a "filter parameters" option in the AppSignal configuration with a list of parameter keys to filter.

Parameter values you've configured to filter out by will be replaced with a [FILTERED] value. This way, the list of parameters in the app data on AppSignal.com still includes the parameter key but not the value, so you still have visibility that a value had potentially sensitive data filtered out before being sent to AppSignal.

Example

For example, an application with this AppSignal config:

YAML
filter_parameters: ["password"]

Results in this view for the parameters of a web request on AppSignal.com:

JSON
{ "password": "[FILTERED]" }

The config method and keys may be different for integrations, see the page below for more information per integration.

Ruby

The AppSignal for Ruby gem has two parameter filtering methods:

AppSignal Parameter Filtering

Use the denylist for basic parameters filtering. This parameter filtering is applied to any query parameters in an HTTP request and any argument for background jobs.

This filtering supports key based filtering for hashes, which will have their values replaced with [FILTERED]. 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.

YAML
# Example: config/appsignal.yml production: filter_parameters: - password - confirm_password

Rails Parameter Filtering

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

AppSignal leverages this request parameter mechanism so both your request logs and the request data sent to AppSignal are filtered by one configuration. Suppose the application should filter the same keys for request parameters and job arguments reported for different Ruby gems, like Sidekiq job arguments. In that case, it's necessary to configure the parameter filtering in AppSignal using the filter_parameters option to also include the keys set in the Rails config as it will not reuse the Rails parameter filtering configuration for those gems.

Denylist: Filtering Specific Keys

There are two ways to determine which keys get filtered. The first one is adding specific keys to the denylist. In the below 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 is more complicated 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.

Allowlist: Allowing Specific Keys

Using a lambda instead of a list of keys gives more flexibility. In the following example, we use a lambda to set up an allowlist instead of a denylist.

Ruby
# 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 make the lambda check any key you'd like, so you can determine and use a filtering method that best suits your application's needs.

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

Elixir

If your app uses Phoenix, you can use the Phoenix parameter filtering. You can use AppSignal's built-in filtering if your app uses a different Elixir framework.

AppSignal parameter filtering

Use the denylist for basic parameters filtering. This parameter filtering is applied to any query parameters in an HTTP request.

Set up parameter filtering using the filter_parameters config option. The filter_parameters value is a List of Strings.

Elixir
# Example: config/appsignal.exs config :appsignal, :config, filter_parameters: ["password", "secret"]

Phoenix filter_parameters Configuration

Use Phoenix's parameter filtering to centralize your config, which is used to keep sensitive information from the logs. AppSignal will follow these filtering rules.

Elixir
# Example: config/config.exs config :phoenix, :filter_parameters, ["password", "secret"]

If the filter_parameters config option is not set, Phoenix will default to ["password"] as a config. This means that a Phoenix app will not send any passwords to AppSignal without any configuration.

Node.js

Use the filterParameters denylist for basic parameter filtering. This filtering is applied to all parameters of an HTTP request.

You can set up parameter filtering using the filterParameters config option. The filterParameters value is an array of strings.

JavaScript
// Example: appsignal.cjs const { Appsignal } = require("@appsignal/nodejs"); new Appsignal({ // Other config options filterParameters: ["password", "secret"], });

Python

Use the filter_parameters denylist for basic parameter filtering. This filtering is applied to all parameters of an HTTP request.

You can set up parameter filtering using the filter_parameters config option. The filter_parameters value is an array of strings.

Python
# __appsignal__.py from appsignal import Appsignal appsignal = Appsignal( # Other config filter_parameters: ["password", "secret"] )