Hide sensitive information

Learn how to hide sensitive information in your bug reports

Bug Capture offers multiple approaches to automatically scrub sensitive information from data before it is uploaded.

Default hidden information

The following data is hidden by default:

• Network requests:
  • The Authorization header
  • All the text after the term password
  • Any word following the keyword Bearer
  • Values following the keys access_token (or accessToken), refresh_token (or refreshToken), id_token (or idToken), decoded_token (or decodedToken)
    These rules are visible, changeable, and restorable in Workspace Settings > General > Data redaction.
• Key presses:
  • In inputs with type="password"
  • In inputs with the autocomplete attribute with one of the following values: current-password, new-password, one-time-code, cc-number, cc-csc, cc-exp.

Hide specific attributes

You can add a custom data-birdeatsbug="ignore" HTML attribute to any element on the page to instruct the browser extension and the SDK to ignore certain types of data:

• Clicks on that specific element or its children
• Key presses on that specific element or its children
• DOM elements will only be recorded as empty elements with the same size as the original element
  The upside of this method is that software developers can exclude sensitive information from being recorded right when they are implementing features that include such data. The redaction will apply to any current or future Bug Capture recorder, independent of its specific configuration. The downside is that source code changes are required, and that only the data points listed above are covered by this feature.

Hide data with regular expressions

Workspace Settings > General > Data redaction allows to configure regular expression patterns to redact sensitive information before a session is uploaded with the browser extension or the SDK. These regular expressions apply to all data visible in the Developer Tools of a recording. In comparison to the data-birdeatsbug="ignore" HTML attribute discussed above, DOM recordings are not affected by this redaction method, and it is not possible to redact which keys where pressed. Regular expressions are handy for reacting console logs and network requests though.

Regular expressions should be as targeted / specific as possible to avoid over-redaction. All regular expressions added to the Data redaction workspace settings are applied to all data visible in the Developer Tools.

The regular expressions entered in the workspace settings should not contain a leading /, or trailing /, nor regular expression options. The values should only be the content of the expression. They will be automatically wrapped with / and the gm options (global, multi-line) when the patterns are passed to a JavaScript RegExp constructor prior to being executed.

Sometimes the value that should be redacted is known up front, or at least the value pattern. But usually there’s a keyword indicating that the following, dynamic value of unknown characters and length should be redacted.

For instance, you’ll want to redact the string following the term password. In these cases, use capturing groups to denote the values that should be replaced with * characters, and the parts of the regular expression outside to match the key terms. The same approach is used to redact the value in key-value pairs, e.g. in network request/response headers, or network request/response JSON.

This will become clearer if you read the examples below:

Network request URLs:

Given a URL http://example.com/login?userName=test&password=insecure&otp=1234, the pattern =[^=&?]*+ will result in the redacted URL http://example.com/login?userName*****&password*********&otp*****.

To just redact the password query parameter on example.com/login, irrespective of query parameter order, we could also use a capture group like example\.com\/login.*password=([^&]*) to receive http://example.com/login?userName=test&password=********&otp=1234.

Network request/response headers

Let’s assume we have a network request with the request headers:

To redact the Authorization request header, we could use the pattern Authorization([^\;]+) to get:

Or, let’s take an imaginary response with this headers:

To redact the token from the Cookie response header, we would configure the expression some-token=([^\;]+) to get:

Network request/response bodies

Imagine a network response body that contains a nested JSON object:

To hide sensitive data in this response, combine the redaction patterns password(.+), isSecret(.+), and creditCardNumber(.+). Every pattern applies to every key/value-pair in the JSON object, even the nested ones.

Note how the boolean value isSecret turned into 4 characters, which prevents understanding whether the value was false before redaction. The 3 letter name is now also 4 letters.

Click events

If we want to hide the text of a clicked element, and also some secret data- attributes, we could use the patterns data-temporary-password(.+) and password is "(.+)" to change this click event:

to this click event:

Errors

Lastly, let’s redact a user ID and the source file paths in the stacktrace of an uncaught error. Here we are using the patterns auth0\|(.+) and \/([^\/]+).js to redact the original event:

…to this redacted error event:

Additional data hiding possibilities in the SDK

The SDK allows to customize the options for DOM recording by passing options to the underlying library, rrweb. Read the DOM Recording page for instructions on customizing this option. rrweb’s privacy options are documented here.

With SDK, you have full programmatic control how the recorded data is mutated before it is uploaded. This code example shows how to do that with the beforeUpload hook.

Disable recording of certain data types

Disabling all data recording of a certain data type like network requests is possible too. This is only a last resort though, as it also prevents the recording of data that can be useful for debugging.

• Instructions for browser extension
• Instructions for the SDK