Sensitive data management

Learn how to redact sensitive data to protect Personal Identifiable Information (PII).

Protecting user privacy and following data protection laws is very important. However, if application settings are not properly configured—especially in error reporting SDKs—personal information (PII) can accidentally be collected and sent to Insight Hub.

This problem is especially important in large-scale mobile deployments. Older versions of applications, which may lack appropriate redaction configurations, can remain in use for extended periods. As a result, even if developers issue a corrected release with improved PII handling, affected versions in the field may continue to leak sensitive data long after the issue is discovered.

To address this, Insight Hub provides a set of tools that allow customers to redact or remove sensitive data retroactively, helping ensure continued compliance with internal policies and data protection regulations such as GDPR, CCPA, and HIPAA.

Adding redaction rules

Redaction rules can be created in the dashboard. This option is available for users of Enterprise plan that are Organization Admins or Project Owners. There are two supported methods for creating a redaction rule:

From an event

Initiate redaction directly from an individual error event. Within the event details menu on the right-hand side, there is an option labeled “Redact sensitive data.” Selecting this option allows users to create a redaction rule on-the-fly based on a specific field observed in the payload. This approach is useful when reacting to newly discovered PII in production data and streamlines the workflow for immediate remediation.

From Project Settings

Navigate to project settings > Sensitive Data Management page within the dashboard. From there, a redaction rule can be created by entering a valid dot notation path that corresponds to the field to be redacted.

Dot notation paths for event redaction

Redaction rules use dot notation to identify the field/key to be redacted within an error event. It uses periods (.) to separate levels of keys, similar to how object properties are accessed in JSON or JavaScript.

Supported root keys

Each valid dot path must begin with one of the following root keys, which correspond to specific domains of the event object. Any path that does not begin with one of these roots will be considered invalid.

Root Path	Description
user.	Fields related to the end user affected by the event, such as ID or email.
app.	Attributes of the application that generated the error, including version and release stage.
device.	Information about the physical or virtual device on which the error occurred.
request.	(web servers only) Details about the HTTP request, including URL, headers, and method.
breadcrumbs[*].	The breadcrumbs that describe the sequence of actions leading to the error.
metaData.	Custom metadata added via the error monitoring SDK, usually be the developer.

Unsupported root keys

Any field outside of the above roots or in the following list are not supported as they are required for the functionality of the dashboard:

• app.deployId
• app.bundleVersion
• app.releaseStage
• app.version
• app.versionCode
• breadcrumbs[*].type
• breadcrumbs[*].timestamp`

Additional considerations

• Paths are case-sensitive
• For array-based data structures such as breadcrumbs, the rule will apply to all elements and so the wildcard operator [*] must be used
• The path must not end with [*] or .
• Paths that attempt to traverse multiple root domains or mix supported and unsupported properties are not permitted.

For best results, consult the event schema documentation before constructing dot paths, especially when using custom metadata.