URL Component Privacy Rules

Who can use this feature?
- Available for all paid plans. 
- Requires an admin role to configure. 

What are URL component privacy rules?

URL component privacy rules allow you to prevent any unwanted or sensitive data within captured URLs from reaching your Fullstory instance. 

To get started, navigate to your Fullstory settings page, scroll down to Privacy, and scroll down until you see the box URL component privacy rules.

URLPrivacy1.png

You will notice there is already a rule present with the name "Default Rule". This is a rule we set for all our customers to block the most common attributes of a URL that may contain sensitive data. This includes the query query params password, token, jwt, and code as well as the hash property #access_token. Click here to learn more.

It's important to note that new or updated rules do NOT work retroactively and will only affect sessions captured after the time of update.

How to create a URL component privacy rule

Creating a rule with one condition

When you click “Create Rule” you will be presented with a modal to define your rule. Your rule name should be descriptive but concise in explaining what this rule is accomplishing. You can add additional details in the description box.

Next comes the actual rule definition. A rule can be broken down into two main components: The condition, and the exclusion.

The condition set in “Apply URL component privacy rule” defines when the following exclusion will take place. For example, if you want your rule to block password text in all URLs of your app, select "to all URLs".

Alternatively, let's say you only want to block user ID text in checkout page URLs. In that case, you should select "when the following are true..." and further define that this rule should only take place when the Path matches /checkout/.

The exclusion is in the section labeled as “Block text in URLs matching” is where you define what specific text you want to be blocked– in the previous examples, this is where we would set the rule to block password text, or user ID text.  In both the condition and exclude sections of the URL component privacy rule you are able to apply a rule targeting the URL Path, Host, Hash, Query Parameter, or Query:

URL Privacy 2.png

At the bottom of the modal you will see a section labeled “Test current rule configuration” This is a tool to enable you to quickly check if your rule is working as intended. Simply paste in a URL and it will show you the output below the text box.

For example if we put in the URL:

https://mywebsite.com/checkout/cart?userId=1234?cartId=abc

URL Privacy 3.png

You can see in the output at the bottom, only the value of the userId query parameter is blocked! This test shows that our rule is configured properly.

How to think about writing URL component privacy rules

While the above example is simple for the sake of teaching, the patterns it demonstrates can be used to cover a majority of your URL privacy needs. A key principle to keep in the back of your head is that you are writing a regular expression to match the pattern of your URLs.

To illustrate this idea, imagine you want to make sure you never capture user emails in your URL. Rather than writing a regular expression to match on all emails, you just have to write a regular expression to match the pattern where user emails are present in your URLs. An example rule could look like:

URL Privacy 4.png

To reiterate, we don’t have to know how to parse for an email, we just have to know that the email will come through via the email query parameter. 

Using multiple conditions

You can define multiple conditions and use them in conjunction with each other in two different ways. These ways are either through grouping the conditions via ANDs and/or ORs. To put it another way, you can define a conditional rule to be as specific as you’d like so that it only excludes data when every single one of those conditions are met. Or, you can create a rule with multiple conditions that will exclude data when any of the conditions are met.

Let’s walk through a couple of examples to illustrate this concept.

First, let's write a rule using multiple AND conditions. Let’s say you have Fullstory running on all of your environments, but you only want the query parameter value for searchQuery to be blocked in your production environment. A rule to do this might look something like this:

URL Privacy 5.png

You can see how the Host AND Path are defined in the conditional part of the rule to narrow down the scope. So in the above picture you can see the value is blocked, however, if we update the test URL to a staging environment for this example you will see that the value remains unblocked since not all of the conditions are matched between our rule and our test:

URL Privacy 6.png

To continue this example in order to illustrate the usage of the OR condition we simply modify our scenario a little bit. Instead of only wanting to block the searchQuery value in their prod environment, they want to block it in their prod and staging environment, but leave it unchanged in their dev environment. To accomplish this, their rule might look something like this:

URL Privacy 7.png

You can see using the same staging URL from the previous example, than the searchQuery value is now blocked. To test our rule, we could update the test URL to a domain different than staging or production. If the rule was set up properly, our output would show that the searchQuery value is not blocked under domains other than the ones we’ve defined.

Broad URL component privacy rule may also impact resource URLs (like the CSS on your site) and, if those CSS resource URLs are blocked as a result of your URL component privacy rules, we will not be able to fetch them for use in recreating the user's experience in session playback. This can result in rendering issues within the session.

Editing a URL component privacy rule

Editing an existing rule is very similar to creating a rule except that all of the definitions currently in place will be pre-populated. All you need to do is adjust the rule and click “update” and the rule will begin using the updated definitions. It should be noted that due to cacheing it might take up to 15 minutes for this new rule to take effect on captured sessions.

Where URLs appear in Fullstory

You can use the URL Component Privacy rules to target the URLs that appear in these places in Fullstory:

Navigation URLs in session playback:

CleanShot

CleanShot

Network URLs in DevTools:

CleanShot

FAQ

Can I edit the default rule?

The default rule cannot be modified. This rule is a catchall for the most common places Fullstory sees sensitive data across all types of web services and in order to protect you and your customers we make sure this rule cannot be modified or deleted.

Who can see and manage URL component privacy rules?

Only Admins can view, create, and edit URL component privacy rules

Do I have to test a URL whenever I create or update a rule?

No, this feature is there only for your benefit but it is not required, though it is strongly encouraged to make sure your rule works as you intend it to.

Are the URLs input into the testing box being sent to Fullstory?

No, we do not capture data from these fields and the rule definitions are being evaluated client side so the data is not being sent to Fullstory servers for processing.

I see more rules in my URL privacy settings than just the default rules, why?

Since Fullstory has supported URL component privacy rules via support requests for quite some time, your organization may have already put in place these rules for capture. If this is the case these rules are being made available for your management through the new URL privacy settings menu.

Looking to exclude other types of data in Fullstory? Please submit your feedback to our support team.

Need to get in touch with us?

The Fullstory Team awaits your every question.

Ask the Community Technical Support