Scrubbing Sensitive Data

As with any third-party service it's important to understand what data is being sent to Sentry, and where relevant ensure sensitive data either never reaches the Sentry servers, or at the very least it doesn’t get stored.

These are some great examples for data scrubbing that every company should think about:

• PII (Personally Identifiable Information) such as a user's name or email address, which post-GDPR should be on every company's mind.
• Authentication credentials, like your AWS password or key.
• Confidential IP (Intellectual Property), such as your favorite color, or your upcoming plans for world domination.

We offer the following options depending on your legal and operational needs:

• filtering or scrubbing sensitive data within the SDK, so that data is not sent to Sentry. Different SDKs have different capabilities, and configuration changes require a redeployment of your application.
• configuring server-side scrubbing to ensure Sentry does not store data. Configuration changes are done in the Sentry UI and apply immediately for new events.
• running a local Relay on your own server between the SDK and Sentry, so that data is not sent to Sentry while configuration can still be applied without deploying.

If you do not wish to use the default PII behavior, you can also choose to identify users in a more controlled manner, using our user identity context.

Scrubbing Data

before_send & before_send_transaction

SDKs provide a before_send hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. Some SDKs also provide a before_send_transaction hook which does the same thing for transactions. We recommend using before_send and before_send_transaction in the SDKs to scrub any data before it is sent, to ensure that sensitive data never leaves the local environment.

#include <sentry.h>

sentry_value_t strip_sensitive_data(sentry_value_t event, void *hint) {
  /* modify event here or return NULL to discard the event */
  return event;
}

int main(void) {
  sentry_options_t *options = sentry_options_new();
  sentry_options_set_before_send(options, strip_sensitive_data, NULL);
  sentry_init(options);

  /* ... */
}

The callback is executed in the same thread as the call to sentry_capture_event. Work performed by the function may thus block the executing thread. For this reason, consider avoiding heavy work in before_send.

Using on_crash

The before_send callback implementation in sentry-native makes it hard to distinguish between normal events and crashes. For this reason, we introduced another callback, on_crash, which - at this point - only exists in sentry_native:

#include <sentry.h>

static sentry_value_t
crash_cleanup(
    const sentry_ucontext_t *uctx, // provides the user-space context of the crash
    sentry_value_t event,          // used the same way as in `before_send`
    void *closure                  // user-data that you can provide at configuration time
)
{
    // Do contextual clean-up before the crash is sent to sentry's backend infrastructure

    /* ... */

    // tell the backend to retain the event (+ dump)
    // or to discard it, you could free the event and return a `null`:
    //       sentry_value_decref(event);
    //       return sentry_value_new_null();
    return event;
}

int main(void) {
  sentry_options_t *options = sentry_options_new();
  sentry_options_set_on_crash(options, crash_cleanup, NULL);
  sentry_init(options);

  /* ... */
}

The on_crash callback replaces before_send as a callback for crash events only. They can be defined simultaneously, where the SDK prevents before_send from being invoked for crash events. This allows for better differentiation between crashes and other events and gradual migration from existing before_send implementations:

• If you have a before_send implementation and do not define an on_crash callback before_send will receive both normal and crash events as before
• If you only want to pre-process normal events with before_send, then you can define an "empty" on_crash callback that returns the passed-in event and does nothing else.
• If you are not interested in pre-processing normal events but only want to act on crashes, then only define an on_crash callback with the option to filter (available for all backends) or enrich (only for inproc) the crash event.

Sensitive data may appear in the following areas:

• Stack-locals → Some SDKs (Python, PHP and Node) will pick up variable values within the stack trace. These can be scrubbed, or this behavior can be disabled altogether if necessary.
• Breadcrumbs → Some SDKs (JavaScript and the Java logging integrations, for example) will pick up previously executed log statements. Do not log PII if using this feature and including log statements as breadcrumbs in the event. Some backend SDKs will also record database queries, which may need to be scrubbed.
• User context → Automated behavior is controlled via send_default_pii.
• HTTP context → Query strings may be picked up in some frameworks as part of the HTTP request context.
• Transaction Names → In certain situations, transaction names might contain sensitive data. For example, a browser's pageload transaction might have a raw URL like /users/1234/details as its name (where 1234 is a user id, which may be considered PII). In most cases, our SDKs can parameterize URLs and routes successfully, that is, turn /users/1234/details into /users/:userid/details. However, depending on the framework, your routing configuration, race conditions, and a few other factors, the SDKs might not be able to completely parameterize all of your URLs.

For more details and data filtering instructions, see Filtering Events.

Examples

Contextual information

Instead of sending confidential information in plaintext, consider hashing it:

Sentry.setTag("birthday", checksumOrHash("08/12/1990"));

This will allow you to correlate it within internal systems if needed, but keep it confidential from Sentry.

User details

Your organization may determine that emails are not considered confidential, but if they are, consider instead sending your internal identifier:

Sentry.setUser({ id: user.id });

// or

Sentry.setUser({ username: user.username });

Doing this will ensure you still benefit from user-impact related features.

Logging integrations

As a best practice you should always avoid logging confidential information. If you have legacy systems you need to work around, consider the following:

• Anonymize the confidential information within the log statements (for example, swap out email addresses -> for internal identifiers)
• Use before_breadcrumb to filter it out from breadcrumbs before it is attached
• Disable logging breadcrumb integration (for example, as described here)