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


For example, an application with this AppSignal config:

filter_parameters: ["password"]

Results in this view for the parameters of a web request on

  "password": "[FILTERED]"

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


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.

# Example: config/appsignal.yml
    - password
    - confirm_password

Rails Parameter Filtering

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

AppSignal leverages this mechanism so you can centralize this configuration, so both your logs and the data sent to AppSignal will be filtered by one configuration.

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

# config/application.rb
module Blog
  class Application < Rails::Application
    config.filter_parameters << :secrets

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.

# config/initializers/parameter_filtering.rb
ALLOWED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.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)

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.


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.

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

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


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.

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

Need more help?

Contact us and speak directly with the engineers working on AppSignal. They will help you get set up, tweak your code and make sure you get the most out of using AppSignal.

Contact us

Start a trial - 30 days free

AppSignal is a great way to monitor your Ruby, Elixir & Node.js applications. Works great with Rails, Phoenix, Express and other frameworks, with support for background jobs too. Let's improve your apps together.

Start a trial