Why does Fullstory use an allowlist approach to Network Request/Response Bodies?

Allowlist Approach

Because the privacy of your customer data is of the utmost importance to Fullstory and in order to ensure that your customer data is protected, Fullstory uses an allowlist approach to capturing Network Request/Response Bodies. This allows you to have control over detailing the specific parts of the Request/Response Bodies that you know are safe to capture and that will be useful for your own debugging process. 

Taking this approach means that in order to capture Request/Response Bodies, you will need to enable Network Allowlisting and also spend time explicitly allowlist individual Request/Response bodies. While it may seem like a quicker solution to enable Network Data Capture for all fields and then blocklist sensitive fields, the risk of inadvertently capturing sensitive customer data is too high. We’ve heard this request before; however, we must weigh the ease of implementation against the potential security risk. As a solution, Fullstory gives you the ability to allowlist only the specific parts of the Request/Response Bodies that you know are safe to capture.


There are additional reasons a blocklist approach to Network Request/Response Bodies could provide more administrative overhead and present considerable risk to your organization.

For example, while you may be confident based on your naming convention that “order-id”, “cc-num”, and “cc-cvv” all include sensitive data, there are often field names that are not descriptive of the data type and could include sensitive data. For instance, the field name “id” could be a simple user ID, but in a JSON tree descriptive of a payment method, “id” could be a payment processor user id.

Furthermore, ensuring an accurate blocklist would require knowing every possible parent > child field path that contains sensitive data for all calls made on your network. This leads to more of a trial and error approach to exclusion, in which you’d run the risk of exposing potentially sensitive information. 

Take the below example:

Network URL: https://www.login-example.com/api/[cust-id]/login

"action": {
"kind": "load-app",
"auth": "simple" <- Definitely want this
"credentials": {
"identity": "<mailto:john@doe.com|john@doe.com>",
"auth": "s3kr!t" <- Don't want this!

In this request body, in order to blocklist the “credential/auth” you would have to know that this contains sensitive data. This request body may be only one of hundreds of different types of Network request bodies that traverse your network. 

If we implemented a blocklist approach you might approach the above request body as follows:




Unfortunately, this would cause you to lose the action/auth field.

If, instead, you specify the following:



Then you could end up with the blocklist failing to match if, for example, some refactoring changes credentials to creds.

Instead, we give you assurance that no potentially sensitive information is captured by implementing our allowlist approach. For the same example, an allowlist that includes all of the action fields and the user id, but not the password, is as simple as this.

URL Pattern


Request bodies - specific fields


Using our allowlist approach to Network Response/Request Bodies, ensures that your users’ privacy is protected in the most secure way. To learn more about how to enable Network Allowlisting, check out this article

Need to get in touch with us?

The Fullstory Team awaits your every question.

Ask the Community Technical Support