Why does FullStory use a whitelist approach to Ajax Request/Response Bodies?

Whitelist 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 a whitelist 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 Whitelisting and also spend time explicitly whitelist individual Request/Response bodies. While it may seem like a faster solution to enable Ajax recording for all fields and then blacklist 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 whitelist only the specific parts of the Request/Response Bodies that you know are safe to record.

Examples

There are additional reasons a blacklist 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 blacklist 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 blacklist 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 blacklist approach you might approach the above request body as follows:

whitelist

   action/*


blacklist:
**/auth

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

If, instead, you specify the following:

whitelist
action/*

blacklist
credentials/auth

Then you could end up with the blacklist 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 whitelist approach. For the same example, a whitelist 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 whitelist 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 Whitelisting, check out this article

Need to get in touch with us?

The FullStory Team awaits your every question.

Contact us