Skip to main content

Data Obfuscation and Encryption

The Network Request Desensitization feature refers to obfuscating sensitive information (such as user identity, account passwords, bank card numbers, ID card numbers, etc.) contained in collected Network Request data. While retaining the request structure and the analyzability of non-sensitive information, it prevents the leakage of sensitive data, balancing the needs of experience analysis with data security and compliance requirements.If you need to obfuscate user input content (such as passwords, phone numbers, etc.) in replay sessions, see Data Collection.

Many customers require SM encryption of data to protect sensitive user-side information and prevent privacy leakage, which can be fulfilled through SM encryption configuration.

Usage Scenarios

  • Data Protection for Payment-Related Requests: In e-commerce and financial applications, Network Requests during the user payment process (such as order submission, payment confirmation) often contain highly sensitive information like bank card numbers and payment passwords.
  • Compliant Handling of User Identity Information: Requests for login and personal information submission in social and medical applications contain private data such as phone numbers, ID card numbers, and medical record numbers.
  • Filtering of Sensitive Parameters in Internal Interfaces: In enterprise-level applications, some internal interfaces (such as employee permission verification, customer management system interfaces) may contain sensitive data like internal codes, permission identifiers, and customer confidential information in their requests.
  • Preventing Sensitive Data from Interfering with Analysis: If some sensitive fields (such as user-defined private notes, chat content) are fully collected, they not only pose privacy risks but may also interfere with normal analysis (such as log retrieval, anomaly troubleshooting) due to disorganized content.
  • Customers require SM encryption: Secures data transmission between the client SDK and the platform using SM encryption to protect sensitive user information and prevent privacy leaks.

Getting Started

Data Obfuscation

Filter which Network Requests require desensitization based on the original request address and domain name. Users can customize whether the filtering conditions are combined using "AND" or "OR" logic.

Desensitization is supported for URL, RequestHeader, and ResponseHeader parameters. You can mask all parameters or specify specific parameters to mask.

Two Data Obfuscation methods are supported:

  • Do Not Collect: This parameter is not collected at all.
  • Obfuscated Collection: The parameter is obfuscated during collection, and the obfuscated part is displayed as "**" on the frontend.

If the same Network Request matches multiple rules, the "Do Not Collect" method takes priority.

image-20251010144842314

Example

Original URL: https://example.com/pay?orderId=P20230915001&cardNo=6222021234567890123&amount=999

Obfuscation TargetObfuscation MethodObfuscated Result
All URL parametersDo Not Collecthttps://example.com/pay
Specified URL parameters orderId, cardNoObfuscated Collectionhttps://example.com/pay?orderId=**&cardNo=**&amount=999
Specified URL parameter amountDo Not Collecthttps://example.com/pay?orderId=P20230915001&cardNo=6222021234567890123

Encryption

SM encryption requires configuration on both the platform and client project sides. Calling this interface enables SM encryption for requests initiated by the SDK itself. The following interface must be called for configuration before the agent starts. Ensure the configuration is consistent with the platform side; otherwise, it may cause exceptions in SDK data requests.

I. Interface Specification

Parameter Name & AnnotationConstraintsFailure Result
keyThe key for SM encryption (must be 16 bytes in length. Do not use the special characters < > & ' " %).Encryption failure or platform-side decryption failure.
identifierThe unique identifier for the corresponding key (length: 1-256 characters. Only alphanumeric characters, underscores _, and hyphens - are supported).Encryption failure or platform-side decryption failure.

II. Configuration Method

  1. Platform-side Nacos Configuration Example:

image-20260127152638915

  1. Client-side Project Configuration Example:

iOS

Objective-C

[BRSAgent enableGMSM4EncryptWithKey:@"qwertyuiopasdfgh" identifier:@"v30"];

Swift:

BRSAgent.enableGMSM4Encrypt(withKey: "qwertyuiopasdfgh", identifier: "v30")

Android:

 byte[] secretKey = new byte[]{q,w,e,r,t,y,u,i,o,p,a,s,d,f,g,h};
//assert secretKey.length == 16;
String identifier="v30";
Bonree.withAppID("<#AppID#>")
.withEnableGMSM4Encrypt(secretKey,identifier)
.start(getApplicationContext());

or

  String secretKeyStr ="qwertyuiopasdfgh";
byte[] secretKey = secretKeyStr.getBytes();
//assert secretKey.length == 16; 务必保证字符实际长度为16字节,请勿使用< > & ' " %特殊字符
String identifier ="v30";
Bonree.withAppID("<#AppID#>")
.withEnableGMSM4Encrypt(secretKey,identifier)
.start(getApplicationContext());

Harmony:

 let secretKey = new Uint8Array([q,w,e,r,t,y,u,i,o,p,a,s,d,f,g,h]); 
//assert secretKey.length == 16;务必保证字符实际长度为16字节,请勿使用< > & ' " %特殊字符
let identifier :string ="v30";
Bonree.withAppID("<#AppID#>")
.withEnableGMSM4Encrypt(secretKey,identifier)
.start(this.context.getApplicationContext())

or

 let secretKeyStr="qwertyuiopasdfgh"
let textEncoder = new util.TextEncoder('utf-8');
let secretKey = textEncoder.encodeInto(secretKeyStr);
//assert secretKey.length == 16;务必保证字符实际长度为16字节,请勿使用< > & ' " %特殊字符
let identifier :string ="v30";
Bonree.withAppID("<#AppID#>")
.withEnableGMSM4Encrypt(secretKey,identifier)
.start(this.context.getApplicationContext())

Web:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<script id="BonreeAgent" src="BonreeSDK_JS.min.js" data=
'{
"appId":"<#AppID#>",
"uploadAddrHttp":"http://<#Upload地址#>",
"uploadAddrHttps":"https://<#Upload地址#>",
"sm4Config":{
"key": "qwertyuiopasdfgh",
"identifier":"v30"
}
}'>
</script>
</head>
<body>
</body>
</html>