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.
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:
filter_parameters: ["password"]
Results in this view for the parameters of a web request on AppSignal.com:
{ "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:
- 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.
# 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]
.
# 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.
# 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.
# 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.
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.
// 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.
# __appsignal__.py from appsignal import Appsignal appsignal = Appsignal( # Other config filter_parameters: ["password", "secret"] )