Server-Side Data Scrubbing

If you can't or don't want to scrub data within the SDK, you can choose from several data scrubbing options in the Sentry app on either an organization-wide or a project level. Data scrubbing is enabled by default and we highly recommend you keep it that way.

To set data scrubbing rules for your entire organization, go to [Settings] > Security & Privacy, and scroll down to the "DATA SCRUBBING" section.

To set them on a per-project basis, go to [Settings] > Projects, select a project, click "Security & Privacy" and scroll down to the "DATA SCRUBBING" section. If organization-wide settings exist, they’ll override any project settings, so be sure to disable them first.

With it enabled, Sentry will scrub the following:

• Values that look like they contain credit cards (using a basic regular expression)
• Values that themselves contain, or whose keynames contain, any of the following strings:
  • password
  • secret
  • passwd
  • api_key
  • apikey
  • access_token
  • auth
  • credentials
  • mysql_pwd
  • stripetoken
  • card[number]
  • github_token
  • privatekey
  • private_key
• Values that contain strings in, or whose keynames are listed in, [Project] > Settings > Security & Privacy in "Additional Sensitive Fields".
  • An entry in "Additional Sensitive Fields" such as mysekret, for example, will cause the removal of any field named mysekret, but also removes any field value that contains mysekret. Sentry does this to protect against sensitive data leaking as part of structured data that has been sent as a single string to Sentry (such as a JSON object that is stringified and embedded as JSON string in another JSON structure).
  • As an extreme example where this behavior can become surprising, the string "Unexpected error" will be removed from events if the entry exp is in "Additional Sensitive Fields".

Sentry will redact arrays and literal values, but also entire objects. For example:

credentials = {
  username: 'jane',
  cats: ['pancake', 'maple', 'hellboy']
  password: 'p4ssw0rd!',
  lastLogin: 'yesterday',
  ...
}

Using the default options will cause the object credentials to be set to null, and the object itself will not be entered. To prevent this from happening add the keyname to Safe Fields (credentials in this case). This will leave the credentials object intact, while making all of its entries subject to scrubbing. So password will be redacted by default, and adding cats, username, and/or lastLogin to the list of additional fields will cause those values to be redacted as well.

Only a select number of fields are scrubbed. You can find a list of the fields that will be scrubbed in Event PII Fields.

In addition, we provide an Advanced Data Scrubbing feature that allows more control over how filters are applied.

Removing Data

If you’ve accidentally sent sensitive data to the server, you likely don't to want to leave it there. There are a few things to note in removal:

• If you send the data as a tagged value, removing the event is not enough. Visit your Project Settings > Tags to permanently remove any related data for a given tag.
• While you cannot delete a single event, you can delete the issue the event is in by clicking the trash icon on the Issue Details page.
• If a large number of unique events - representing multiple issues - contain the data, you may need to delete and re-create the project to effectively cleanse the system.

Safe Fields

Safe Fields are used to exclude fields and data from scrubbing. For example, take the following event payload:

{
  "user": {
    "id": "4111111111111111"
  },
  "extra": {
    "id": "sensitive",
    "sys.argv": ["script.py", "password"],
    "credentials": {"username": "jane", "password": "p4ssw0rd!"}
  }
}

When scrubbing is enabled and id added as a sensitive field, the password string in extra.'sys.argv', both id fields (user.id and extra.id), as well as the entire credentials object will be scrubbed.

To accomodate more fine-grained filtering, the Safe Fields support the same syntax as the Advanced Datascrubbing Sources.

If you want to leave the user.id field intact, you can configure the id as a Safe Field, but this will also mark extra.id as a Safe Field. To specifically select the user id, use the full path instead of user.id.

Marking elements of an array as safe requires a wildcard selector, for example 'sys.argv'.*. A deep wildcard can be used to mark all elements contained within an object. The two selectors: extra.credentials and extra.credentials.** will mark the credentials object and all of its members as safe.

Known Limitations

It's not currently possible to avoid scrubbing data in breadcrumbs by adding the category name in "Safe Fields". Only the message and data in breadcrumbs are used for data scrubbing. Also, if custom JSON data is provided, the fields will be scrubbed according to the configured rules and the entries in "Safe Fields".