Why does FullStory use a allowlist approach to Ajax 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 recording Ajax 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 record and that will be useful for your own debugging process. 

Taking this approach means that in order to record Request/Response Bodies, you will need to enable Ajax Allowlisting and also spend time explicitly allowlist individual Request/Response bodies. While it may seem like a faster solution to enable Ajax recording for all fields and then blocklist sensitive fields, the risk of inadvertently recording 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 record.

Examples

There are additional reasons a blocklist approach to AJAX 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 AJAX 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:

AJAX 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 AJAX request bodies that traverse your network. 

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

allowlist

   action/*


bl0cklist:
**/auth

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

If, instead, you specify the following:

allowlist
action/*

blocklit
credentials/auth

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, a allowlist that includes all of the action fields and the user id, but not the password, is as simple as this.

URL Pattern

.*www.login-example.com/api/.*/login

Request bodies - specific fields

action/**
credentials/identity

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

Need to get in touch with us?

The FullStory Team awaits your every question.

Contact us