> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

<Tip>
  Read more about parameter filtering in our [Parameter Filtering][parameter
      filtering] documentation.
</Tip>

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

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

<Tip>
  Some [parameter keys are also removed by our
  processor](/application/parameter-filtering#processor-parameter-filtering)
  on our servers.
</Tip>

### Example

For example, an application with this AppSignal config:

<CodeGroup>
  ```yaml YAML theme={null}
  filter_parameters: ["password"]
  ```
</CodeGroup>

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

<CodeGroup>
  ```json JSON theme={null}
  {
    "password": "[FILTERED]"
  }
  ```
</CodeGroup>

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

* [Ruby](#ruby)
* [Elixir](#elixir)
* [Node.js](#nodejs)
* [Python](#python)
* [Go](#go)
* [Java](#java)
* [PHP](#php)

## Ruby

The [AppSignal for Ruby](/ruby) gem has two parameter filtering methods:

* If your app uses Rails, you can use the [Rails configuration directly](/guides/filter-data/filter-parameters#rails-parameter-filtering).
* If your app uses another framework, like Sinatra or Padrino, you can use [AppSignal's built-in filtering](#rails-parameter-filtering) instead.

### AppSignal Parameter Filtering {/* id: 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`](/ruby/configuration/options#option-filter_parameters) value is an array of strings.

<CodeGroup>
  ```ruby Ruby theme={null}
  Appsignal.configure do |config|
    config.filter_parameters << "password"
  end
  ```

  ```yaml YAML theme={null}
  production:
    filter_parameters:
      - password
      - confirm_password
  ```
</CodeGroup>

### 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](/ruby/configuration/options#option-filter_parameters) 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]`.

<CodeGroup>
  ```ruby Ruby theme={null}
  module Blog
    class Application < Rails::Application
      config.filter_parameters << :secrets
    end
  end
  ```
</CodeGroup>

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.

<CodeGroup>
  ```ruby Ruby theme={null}
  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
  ```
</CodeGroup>

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](http://guides.rubyonrails.org/action_controller_overview.html#parameters-filtering).

## Elixir

If your app uses Phoenix, you can use the [Phoenix parameter filtering](/guides/filter-data/filter-parameters#phoenix-filter_parameters-configuration). You can use AppSignal's built-in filtering if your app uses a different Elixir framework.

### AppSignal parameter filtering {/* id: elixir-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](/elixir/configuration/options#option-filter_parameters). The filter\_parameters value is a List of Strings.

<CodeGroup>
  ```elixir Elixir theme={null}
  config :appsignal, :config,
    filter_parameters: ["password", "secret"]
  ```
</CodeGroup>

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

<CodeGroup>
  ```elixir Elixir theme={null}
  config :phoenix,
    :filter_parameters, ["password", "secret"]
  ```
</CodeGroup>

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](/nodejs/3.x/configuration/options#option-filterparameters). The `filterParameters` value is an array of strings.

<CodeGroup>
  ```javascript Node.js theme={null}
  const { Appsignal } = require("@appsignal/nodejs");

  new Appsignal({
    // Other config options
    filterParameters: ["password", "secret"],
  });
  ```
</CodeGroup>

## 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](/python/configuration/options#option-filter_parameters). The `filter_parameters` value is an array of strings.

<CodeGroup>
  ```python Python theme={null}
  from appsignal import Appsignal

  appsignal = Appsignal(
      # Other config
      filter_parameters: ["password", "secret"]
  )
  ```
</CodeGroup>

## 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](/go/configuration/options#option-filter_request_query_parameters) for request query parameter filtering. Set the [`send_request_query_parameters` option](/go/configuration/options#option-send_request_query_parameters) to `false` to not send any request query parameters at all.

Use the [`filter_request_payload` denylist](/go/configuration/options#option-filter_request_payload) for request payload data filtering. Set the [`send_request_payload` option](/go/configuration/options#option-send_request_payload) to `false` to not send any request payload data at all.

See the [Go configuration page](/go/configuration/options) for more information on how to configure OpenTelemetry for Go apps.

<CodeGroup>
  ```go Go theme={null}
  res := resource.NewWithAttributes(
  	attribute.StringSlice("appsignal.config.filter_request_query_parameters", []string{"password", "cvv"}),
  	attribute.StringSlice("appsignal.config.filter_request_payload", []string{"password", "cvv"}),
  )
  ```
</CodeGroup>

## 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](/java/configuration/options#option-filter_request_query_parameters) for request query parameter filtering. Set the [`send_request_query_parameters` option](/java/configuration/options#option-send_request_query_parameters) to `false` to not send any request query parameters at all.

Use the [`filter_request_payload` denylist](/java/configuration/options#option-filter_request_payload) for request payload data filtering. Set the [`send_request_payload` option](/java/configuration/options#option-send_request_payload) to `false` to not send any request payload data at all.

See the [Java configuration page](/java/configuration/options) for more information on how to configure OpenTelemetry for Java apps.

<CodeGroup>
  ```bash Bash theme={null}
  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"),\
    ..."
  ```
</CodeGroup>

## 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](/php/configuration/options#option-filter_request_query_parameters) for request query parameter filtering. Set the [`send_request_query_parameters` option](/php/configuration/options#option-send_request_query_parameters) to `false` to not send any request query parameters at all.

Use the [`filter_request_payload` denylist](/php/configuration/options#option-filter_request_payload) for request payload data filtering. Set the [`send_request_payload` option](/php/configuration/options#option-send_request_payload) to `false` to not send any request payload data at all.

See the [PHP configuration page](/php/configuration/options) for more information on how to configure AppSignal for PHP.

<CodeGroup>
  ```php PHP theme={null}
  return [
      'filter_request_query_parameters' => ['password', 'cvv'],
      'filter_request_payload' => ['password', 'cvv'],
      // ... other options
  ];
  ```
</CodeGroup>

[parameter filtering]: /application/parameter-filtering.html