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.

Some parameter keys are also removed by our processor on our servers.

Example

For example, an application with this AppSignal config:

filter_parameters: ["password"]

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

{
  "password": "[FILTERED]"
}

This guide will show you how to configure your application’s parameter filtering denylist based on what language your application uses:

Ruby
Elixir
Node.js
Python
Go
Java
PHP

Ruby

The AppSignal for Ruby gem has two parameter filtering methods:

If your app uses Rails, you can use the Rails configuration directly.
If your app uses another framework, like Sinatra or Padrino, you can use AppSignal’s built-in filtering instead.

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.

Appsignal.configure do |config|
  config.filter_parameters << "password"
end

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].

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.

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.

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.

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.

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.

from appsignal import Appsignal

appsignal = Appsignal(
    # Other config
    filter_parameters: ["password", "secret"]
)

Go

For Go, we report the request parameters as query parameters (?query=text) and payload data (POST request payload). Use the filter_request_query_parameters denylist for request query parameter filtering. Set the send_request_query_parameters option to false to not send any request query parameters at all. Use the filter_request_payload denylist for request payload data filtering. Set the send_request_payload option to false to not send any request payload data at all. See the Go configuration page for more information on how to configure OpenTelemetry for Go apps.

res := resource.NewWithAttributes(
	attribute.StringSlice("appsignal.config.filter_request_query_parameters", []string{"password", "cvv"}),
	attribute.StringSlice("appsignal.config.filter_request_payload", []string{"password", "cvv"}),
)

Java

For Java, we report the request parameters as query parameters (?query=text) and payload data (POST request payload). Use the filter_request_query_parameters denylist for request query parameter filtering. Set the send_request_query_parameters option to false to not send any request query parameters at all. Use the filter_request_payload denylist for request payload data filtering. Set the send_request_payload option to false to not send any request payload data at all. See the Java configuration page for more information on how to configure OpenTelemetry for Java apps.

function encode() {
  echo -n "$@" | sed 's/,/%2C/g'
}

export OTEL_RESOURCE_ATTRIBUTES="\
  appsignal.config.filter_request_query_parameters=$(encode "password,cvv"),\
  appsignal.config.filter_request_payload=$(encode "password,cvv"),\
  ..."

PHP

For PHP, we report the request parameters as query parameters (?query=text) and payload data (POST request payload). Use the filter_request_query_parameters denylist for request query parameter filtering. Set the send_request_query_parameters option to false to not send any request query parameters at all. Use the filter_request_payload denylist for request payload data filtering. Set the send_request_payload option to false to not send any request payload data at all. See the PHP configuration page for more information on how to configure AppSignal for PHP.

return [
    'filter_request_query_parameters' => ['password', 'cvv'],
    'filter_request_payload' => ['password', 'cvv'],
    // ... other options
];

Homepage

Guides

Parameter Filtering

Example

Ruby

AppSignal Parameter Filtering

Rails Parameter Filtering

Denylist: Filtering Specific Keys

Allowlist: Allowing Specific Keys

Elixir

AppSignal parameter filtering

Phoenix filter_parameters Configuration

Node.js

Python

Go

Java

PHP

​Parameter Filtering

​Example

​Ruby

​AppSignal Parameter Filtering

​Rails Parameter Filtering

​Denylist: Filtering Specific Keys

​Allowlist: Allowing Specific Keys

​Elixir

​AppSignal parameter filtering

​Phoenix filter_parameters Configuration

​Node.js

​Python

​Go

​Java

​PHP

Parameter Filtering

Example

Ruby

AppSignal Parameter Filtering

Rails Parameter Filtering

Denylist: Filtering Specific Keys

Allowlist: Allowing Specific Keys

Elixir

AppSignal parameter filtering

Phoenix filter_parameters Configuration

Node.js

Python

Go

Java

PHP