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.
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:
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
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:
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:
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:
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:
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.
Excluding everything except for what you specifically want
A type of rule that can be very useful and easier to manage is one that simply blocks everything of a certain type except the ones you don’t want to block. In other words, you allowlist the values you want to see and default to blocking anything else. This can be used as a safe approach if you don’t know all the query param names your organization might use but you do know which ones are needed to enhance your FullStory experience and don’t contain any sensitive information.
To achieve this kind of rule we can use the regular expression negative lookahead operator. For this example let's assume you want to block all query params except for storeId, productId, and referral.
Using this example url:
mywebsite.com/checkout?location=Atlanta?storeId=1234?productId=xyz?paymentMethod=visa?referral=false
We can get a rule defined like this:
As you can see all the query parameters that do not match our defined allowlisted fields are blocked.
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:
Network URLs in DevTools:
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
What's the difference between Query and Query Parameter?
Query accounts for the full query value following the ? in a URL while the query parameter is each individual parameter within the URL. Let's take this URL for example: https://mywebsite.com/login?myEmail=foobar@fullstory.com&myUsername=foo
The Query for this URL is myEmail=foobar@fullstory.com&myUsername=foo
Each of the Query Parameters in this URL are myEmail=foobar@fullstory.com and myUsername=foo
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.